libgdl again: opinions please!
Hi all,
To follow up our recent discussions about building against an external copy of libgdl (https://launchpad.net/bugs/792115)...
I have played with the code, and here is a summary of my findings:
The Inkscape fork of GDL is branched from gdl-0.7.7, which was released a loooong time ago. There have been very substantial upstream changes/bug-fixes since then. In particular, our version uses lots of deprecated/obsolete GTK calls, meaning that Inkscape will fail to build against GTK 3. We therefore need to fix this issue fairly quickly.
Our fork of GDL introduces a couple of new features. Here are the main ones I can see: * Focus switching between docked dialogs, with tab/arrow-key bindings * Ability to create a docked dialog using a pixbuf icon.
I have forwarded a patch upstream to GDL (https://bugzilla.gnome.org/show_bug.cgi?id=652248) asking if they would be able to merge any of our changes. The upstream developer was very supportive and helpful, and had a few queries. However, I'm not an expert on GDL/GTK and I'm not in the best position to comment.
I see three options for fixing the problem: 1) Build against external GDL right away --- This should be easy to do, but we'd lose our changes for a while. However, I'm not sure any of the changes represent essential Inkscape design features and we'd be able to reimplement them when they appear in the upstream API.
2) Merge our changes into upstream GDL 2.30 and copy this into the Inkscape code --- This will take a bit of fiddling around, and it still relies upon us working with forked code. I have managed to make a branch of inkscape with gdl-2.3.0+changes that compiles and runs, but it is buggy (no colour switching and some graphics glitches). Unfortunately, my GTK knowledge is not good enough for me to do this by myself. If anyone is able & willing to help, I can push the new branch.
3) Don't fix it yet! --- Wait until upstream have implemented all the changes (in GDL >=3.1.1) and then switch over. However, we have no guarantee of how long this will take, and we will be unable to support GDK+ 3 builds until we switch!
Please let me know what you think!
AV
Hey Alex,
For the most part I'd actually be all for the first option... temporary loss of a way of using things that a good number of people probably don't use is just a temporary set back. However, can you explain how we use "Ability to create a docked dialog using a pixbuf icon."? Unless there's something pretty major with that, I vote for solution 1. Also, is gdl on the typical 6-month gtk release cycle?
Cheers, Josh
On Sun, Jun 12, 2011 at 7:10 AM, Alex Valavanis <valavanisalex@...400...>wrote:
Hi all,
To follow up our recent discussions about building against an external copy of libgdl (https://launchpad.net/bugs/792115)...
I have played with the code, and here is a summary of my findings:
The Inkscape fork of GDL is branched from gdl-0.7.7, which was released a loooong time ago. There have been very substantial upstream changes/bug-fixes since then. In particular, our version uses lots of deprecated/obsolete GTK calls, meaning that Inkscape will fail to build against GTK 3. We therefore need to fix this issue fairly quickly.
Our fork of GDL introduces a couple of new features. Here are the main ones I can see:
- Focus switching between docked dialogs, with tab/arrow-key bindings
- Ability to create a docked dialog using a pixbuf icon.
I have forwarded a patch upstream to GDL (https://bugzilla.gnome.org/show_bug.cgi?id=652248) asking if they would be able to merge any of our changes. The upstream developer was very supportive and helpful, and had a few queries. However, I'm not an expert on GDL/GTK and I'm not in the best position to comment.
I see three options for fixing the problem:
- Build against external GDL right away --- This should be easy to
do, but we'd lose our changes for a while. However, I'm not sure any of the changes represent essential Inkscape design features and we'd be able to reimplement them when they appear in the upstream API.
- Merge our changes into upstream GDL 2.30 and copy this into the
Inkscape code --- This will take a bit of fiddling around, and it still relies upon us working with forked code. I have managed to make a branch of inkscape with gdl-2.3.0+changes that compiles and runs, but it is buggy (no colour switching and some graphics glitches). Unfortunately, my GTK knowledge is not good enough for me to do this by myself. If anyone is able & willing to help, I can push the new branch.
- Don't fix it yet! --- Wait until upstream have implemented all the
changes (in GDL >=3.1.1) and then switch over. However, we have no guarantee of how long this will take, and we will be unable to support GDK+ 3 builds until we switch!
Please let me know what you think!
AV
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Josh,
The small icons that appear in the handle of our docked dialogs are all rendered in this manner as far as I can tell. At the moment, upstream gdl only allows dialogs to be created either with no icon in the handle at all [gdl_dock_item_new()] or with a stock icon in the handle [gdl_dock_item_new_with_stock()]. We have added a new option [gdl_dock_item_new_with_pixbuf_icon()] that allows a pixbuf icon to be used in the handle.
I have pushed a new branch lp:~inkscape.dev/inkscape/external-gdl that builds against an external copy of gdl and disables our new features. Please feel free to try it out! Here are a few notes:
* I set version gdl-1.0 >= 2.30.1 for pkg-config. This is the upstream stable version, and the one that is shipped with Ubuntu Natty. I haven't checked which version is provided by other distros. * Docked dialogs no longer display any icon in the handle. In principle, it should still be possible to create dialogs with an icon, by registering the desired icon as a new stock icon. I have no experience with doing this, however... and I don't know the best way to tackle it in Inkscape! * Docked dialogs no longer grab keyboard focus... this is a bit annoying, because you cannot tab-select input fields.
Hope that's of some use!
AV
On 12 June 2011 19:43, Josh Andler <scislac@...400...> wrote:
Hey Alex,
For the most part I'd actually be all for the first option... temporary loss of a way of using things that a good number of people probably don't use is just a temporary set back. However, can you explain how we use "Ability to create a docked dialog using a pixbuf icon."? Unless there's something pretty major with that, I vote for solution 1. Also, is gdl on the typical 6-month gtk release cycle?
Cheers, Josh
On Sun, Jun 12, 2011 at 7:10 AM, Alex Valavanis <valavanisalex@...400...> wrote:
Hi all,
To follow up our recent discussions about building against an external copy of libgdl (https://launchpad.net/bugs/792115)...
I have played with the code, and here is a summary of my findings:
The Inkscape fork of GDL is branched from gdl-0.7.7, which was released a loooong time ago. There have been very substantial upstream changes/bug-fixes since then. In particular, our version uses lots of deprecated/obsolete GTK calls, meaning that Inkscape will fail to build against GTK 3. We therefore need to fix this issue fairly quickly.
Our fork of GDL introduces a couple of new features. Here are the main ones I can see:
- Focus switching between docked dialogs, with tab/arrow-key bindings
- Ability to create a docked dialog using a pixbuf icon.
I have forwarded a patch upstream to GDL (https://bugzilla.gnome.org/show_bug.cgi?id=652248) asking if they would be able to merge any of our changes. The upstream developer was very supportive and helpful, and had a few queries. However, I'm not an expert on GDL/GTK and I'm not in the best position to comment.
I see three options for fixing the problem:
- Build against external GDL right away --- This should be easy to
do, but we'd lose our changes for a while. However, I'm not sure any of the changes represent essential Inkscape design features and we'd be able to reimplement them when they appear in the upstream API.
- Merge our changes into upstream GDL 2.30 and copy this into the
Inkscape code --- This will take a bit of fiddling around, and it still relies upon us working with forked code. I have managed to make a branch of inkscape with gdl-2.3.0+changes that compiles and runs, but it is buggy (no colour switching and some graphics glitches). Unfortunately, my GTK knowledge is not good enough for me to do this by myself. If anyone is able & willing to help, I can push the new branch.
- Don't fix it yet! --- Wait until upstream have implemented all the
changes (in GDL >=3.1.1) and then switch over. However, we have no guarantee of how long this will take, and we will be unable to support GDK+ 3 builds until we switch!
Please let me know what you think!
AV
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2011/6/12 Alex Valavanis <valavanisalex@...400...>:
Hi Josh,
The small icons that appear in the handle of our docked dialogs are all rendered in this manner as far as I can tell. At the moment, upstream gdl only allows dialogs to be created either with no icon in the handle at all [gdl_dock_item_new()] or with a stock icon in the handle [gdl_dock_item_new_with_stock()]. We have added a new option [gdl_dock_item_new_with_pixbuf_icon()] that allows a pixbuf icon to be used in the handle.
I think the best solution would be to expose the GtkImage widget that displays the dock icon as a property, so that we can use gtk_image_set_from_pixbuf or gtk_image_set_from_icon_name on it.
Regards, Krzysztof
On Jun 12, 2011, at 2:53 PM, Krzysztof Kosiński wrote:
2011/6/12 Alex Valavanis <valavanisalex@...400...>:
Hi Josh,
The small icons that appear in the handle of our docked dialogs are all rendered in this manner as far as I can tell. At the moment, upstream gdl only allows dialogs to be created either with no icon in the handle at all [gdl_dock_item_new()] or with a stock icon in the handle [gdl_dock_item_new_with_stock()]. We have added a new option [gdl_dock_item_new_with_pixbuf_icon()] that allows a pixbuf icon to be used in the handle.
I think the best solution would be to expose the GtkImage widget that displays the dock icon as a property, so that we can use gtk_image_set_from_pixbuf or gtk_image_set_from_icon_name on it.
That might not be the best.
Among other things you end up with a single-sized bitmap that is used regardless of situation and user preferences. It is much more flexible to use a custom stock icon. Since Inkscape hooks itself in as a provider of stock icons, it can supply any as needed, and with dynamic sizing.
Work-arounds include rendering and grabbing a pixmap early in the process, but that has led to many bugs, including some significant crashing in many apps (not just Inkscape). But that a proper solution fixes crashing without need for work-around code, and also provides proper dynamic sizing, makes it a much better choice.
Regardless, gtk_image_set_from_pixbuf should be avoided.
2011/6/13 Jon Cruz <jon@...18...>:
Among other things you end up with a single-sized bitmap that is used regardless of situation and user preferences.
When you use gtk_image_set_from_icon_name the optimal size present in the theme is picked, so this functionality is not unique to stock items (also see below).
It is much more flexible to use a custom stock icon.
GtkImage can display stock items. Are you arguing against using gtk_image_set_from_pixbuf (which I agree is not the best idea, but we can use it temporarily) or against exposing GtkImage as a property?
Regards, Krzysztof
On Jun 12, 2011, at 3:32 PM, Krzysztof Kosiński wrote:
2011/6/13 Jon Cruz <jon@...18...>:
Among other things you end up with a single-sized bitmap that is used regardless of situation and user preferences.
When you use gtk_image_set_from_icon_name the optimal size present in the theme is picked, so this functionality is not unique to stock items (also see below).
It is much more flexible to use a custom stock icon.
GtkImage can display stock items. Are you arguing against using gtk_image_set_from_pixbuf (which I agree is not the best idea, but we can use it temporarily) or against exposing GtkImage as a property?
First and foremost I was pointing out that existing code already allows one to achieve the needed goal without adding any changes to the library. Pushing out changes to app code that require end users to wait for their distros to pick up new versions of libs (or, more often, to wait and then upgrade to a newer distro to get newer libs) is often a poor choice.
The main objection I would have is to using gtk_image_set_from_pixbuf. That is really a non-solution in light of all the problems it gives, and the missing functionality when using it. Then exposing GtkImage also might be sub-optimal. When going that route, things start to be similar to "gee, I'm not sure what to do so I'll just import random assembly code from the user and run that".
There are dynamic subtleties that GtkImage itself does not provide, but require additional custom code to gain. Named icons (as opposed to certain other GtkImage types) have a lot of that missing behavior, but stock icons give even more. One *could* replace their use with GtkImage, but then might not be aware of what is missed, or could be missed. If an API allows users to pass in random things, but only behaves correctly when users pass in only *certain* things, then that is a poor API. On the other hand, an API that only allows one to pass in items that will result in good behavior (stock or named icon names as opposed to arbitrary GtkImage instances, for example) is usually a better one.
2011/6/12 Jon Cruz <jon@...18...>
On Jun 12, 2011, at 3:32 PM, Krzysztof Kosiński wrote:
First and foremost I was pointing out that existing code already allows one to achieve the needed goal without adding any changes to the library. Pushing out changes to app code that require end users to wait for their distros to pick up new versions of libs (or, more often, to wait and then upgrade to a newer distro to get newer libs) is often a poor choice.
Often a poor choice? Yes. Sometimes for the betterment of the project? Yes. 0.49 or whatever version it will end up as is truly a game changer for us. New versioning scheme, it appears the cmake cross-platform building will take, cairo renderer, purging our internal copies of libcroco (of which Abhishek is now a maintainer) & libgdl... to me, this release will really be one of those "you're best off on the most up-to-date distros" releases. Will we require it? No. Will there possibly be known issues with older libraries. Yes. I'm making this as a general statement, not just in regards to any patches we may be waiting for gdl to accept.
Cheers, Josh
On Jun 12, 2011, at 7:21 PM, Josh Andler wrote:
2011/6/12 Jon Cruz <jon@...18...>
First and foremost I was pointing out that existing code already allows one to achieve the needed goal without adding any changes to the library. Pushing out changes to app code that require end users to wait for their distros to pick up new versions of libs (or, more often, to wait and then upgrade to a newer distro to get newer libs) is often a poor choice.
Often a poor choice? Yes. Sometimes for the betterment of the project? Yes. 0.49 or whatever version it will end up as is truly a game changer for us. New versioning scheme, it appears the cmake cross-platform building will take, cairo renderer, purging our internal copies of libcroco (of which Abhishek is now a maintainer) & libgdl... to me, this release will really be one of those "you're best off on the most up-to-date distros" releases. Will we require it? No. Will there possibly be known issues with older libraries. Yes. I'm making this as a general statement, not just in regards to any patches we may be waiting for gdl to accept.
That is true... however the main point in this specific case is that the functionality under discussion (icons) can be achieved without changing any API's and pushing things out to external libs. And combined with the fact that the one change being looked at introduces many problems, avoiding a lib API change can be good here.
@Josh - The upstream developer sounded very positive about accepting some/all of our changes (https://bugzilla.gnome.org/show_bug.cgi?id=652248). I guess the focus-switching is the most critical issue... we can live without icons, and as per the preceding discussion, it should be possible just to use the existing API if we decide we want to. I have asked Johannes from gdl if he would be happy to add this feature and if he can estimate an ETA.
AV
On 13 June 2011 05:32, Jon Cruz <jon@...18...> wrote:
On Jun 12, 2011, at 7:21 PM, Josh Andler wrote:
2011/6/12 Jon Cruz <jon@...18...>
First and foremost I was pointing out that existing code already allows one to achieve the needed goal without adding any changes to the library. Pushing out changes to app code that require end users to wait for their distros to pick up new versions of libs (or, more often, to wait and then upgrade to a newer distro to get newer libs) is often a poor choice.
Often a poor choice? Yes. Sometimes for the betterment of the project? Yes. 0.49 or whatever version it will end up as is truly a game changer for us. New versioning scheme, it appears the cmake cross-platform building will take, cairo renderer, purging our internal copies of libcroco (of which Abhishek is now a maintainer) & libgdl... to me, this release will really be one of those "you're best off on the most up-to-date distros" releases. Will we require it? No. Will there possibly be known issues with older libraries. Yes. I'm making this as a general statement, not just in regards to any patches we may be waiting for gdl to accept.
That is true... however the main point in this specific case is that the functionality under discussion (icons) can be achieved without changing any API's and pushing things out to external libs. And combined with the fact that the one change being looked at introduces many problems, avoiding a lib API change can be good here.
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 12/6/11 21:37, Alex Valavanis wrote:
- Docked dialogs no longer grab keyboard focus... this is a bit
annoying, because you cannot tab-select input fields.
On 13/6/11 10:30, Alex Valavanis wrote:
@Josh - The upstream developer sounded very positive about accepting some/all of our changes (https://bugzilla.gnome.org/show_bug.cgi?id=652248). I guess the focus-switching is the most critical issue... we can live without icons, and as per the preceding discussion, it should be possible just to use the existing API if we decide we want to. I have asked Johannes from gdl if he would be happy to add this feature and if he can estimate an ETA.
The focus switching seems to trigger other UI/workflow issues in Inkscape's GUI though. I haven't built the branch with the external gdl yet - to be able to compare - but will provide some links to the bug tracker [1]: several reports (+duplicates) are about keyboard shortcuts trapped by docked dialogs - failing without explicitly moving the focus back to the canvas or even causing status changes in the current document (for example making 'root' the current drawing level even though 'root' is normally not accessible from within the GUI).
Before committing changes upstream, maybe those issues can be investigated if they are due to local changes in gdl, possibly limited to ported platforms only or need to be addressed elsewhere in Inkscape's code?
~suv
[1] some (IMHO) related reports:
Bug #201203 in Inkscape: “focus issues when using docked palettes”: https://bugs.launchpad.net/inkscape/+bug/201203
Bug #505225 in Inkscape: “Layer text box popup”: https://bugs.launchpad.net/inkscape/+bug/505225
Bug #666512 in Inkscape: “Cannot use keyboard to move layer up/down”: https://bugs.launchpad.net/inkscape/+bug/666512
Bug #768103 in Inkscape: “Alt+B does not create a bitmap copy if same mnemonic is defined in docked dialog”: https://bugs.launchpad.net/inkscape/+bug/768103
Tested and commented on all those branches.
On Mon, Jun 13, 2011 at 2:16 AM, ~suv <suv-sf@...58...> wrote:
On 12/6/11 21:37, Alex Valavanis wrote:
- Docked dialogs no longer grab keyboard focus... this is a bit
annoying, because you cannot tab-select input fields.
On 13/6/11 10:30, Alex Valavanis wrote:
@Josh - The upstream developer sounded very positive about accepting some/all of our changes (https://bugzilla.gnome.org/show_bug.cgi?id=652248). I guess the focus-switching is the most critical issue... we can live without icons, and as per the preceding discussion, it should be possible just to use the existing API if we decide we want to. I have asked Johannes from gdl if he would be happy to add this feature and if he can estimate an ETA.
The focus switching seems to trigger other UI/workflow issues in Inkscape's GUI though. I haven't built the branch with the external gdl yet - to be able to compare - but will provide some links to the bug tracker [1]: several reports (+duplicates) are about keyboard shortcuts trapped by docked dialogs - failing without explicitly moving the focus back to the canvas or even causing status changes in the current document (for example making 'root' the current drawing level even though 'root' is normally not accessible from within the GUI).
Before committing changes upstream, maybe those issues can be investigated if they are due to local changes in gdl, possibly limited to ported platforms only or need to be addressed elsewhere in Inkscape's code?
~suv
[1] some (IMHO) related reports:
Bug #201203 in Inkscape: “focus issues when using docked palettes”: https://bugs.launchpad.net/inkscape/+bug/201203
Bug #505225 in Inkscape: “Layer text box popup”: https://bugs.launchpad.net/inkscape/+bug/505225
Bug #666512 in Inkscape: “Cannot use keyboard to move layer up/down”: https://bugs.launchpad.net/inkscape/+bug/666512
Bug #768103 in Inkscape: “Alt+B does not create a bitmap copy if same mnemonic is defined in docked dialog”: https://bugs.launchpad.net/inkscape/+bug/768103
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
All those BUGS not branches... with the external-gdl branch.
On Mon, Jun 13, 2011 at 11:22 AM, Josh Andler <scislac@...400...> wrote:
Tested and commented on all those branches.
On Mon, Jun 13, 2011 at 2:16 AM, ~suv <suv-sf@...58...>wrote:
On 12/6/11 21:37, Alex Valavanis wrote:
- Docked dialogs no longer grab keyboard focus... this is a bit
annoying, because you cannot tab-select input fields.
On 13/6/11 10:30, Alex Valavanis wrote:
@Josh - The upstream developer sounded very positive about accepting some/all of our changes (https://bugzilla.gnome.org/show_bug.cgi?id=652248). I guess the focus-switching is the most critical issue... we can live without icons, and as per the preceding discussion, it should be possible just to use the existing API if we decide we want to. I have asked Johannes from gdl if he would be happy to add this feature and if he can estimate an ETA.
The focus switching seems to trigger other UI/workflow issues in Inkscape's GUI though. I haven't built the branch with the external gdl yet - to be able to compare - but will provide some links to the bug tracker [1]: several reports (+duplicates) are about keyboard shortcuts trapped by docked dialogs - failing without explicitly moving the focus back to the canvas or even causing status changes in the current document (for example making 'root' the current drawing level even though 'root' is normally not accessible from within the GUI).
Before committing changes upstream, maybe those issues can be investigated if they are due to local changes in gdl, possibly limited to ported platforms only or need to be addressed elsewhere in Inkscape's code?
~suv
[1] some (IMHO) related reports:
Bug #201203 in Inkscape: “focus issues when using docked palettes”: https://bugs.launchpad.net/inkscape/+bug/201203
Bug #505225 in Inkscape: “Layer text box popup”: https://bugs.launchpad.net/inkscape/+bug/505225
Bug #666512 in Inkscape: “Cannot use keyboard to move layer up/down”: https://bugs.launchpad.net/inkscape/+bug/666512
Bug #768103 in Inkscape: “Alt+B does not create a bitmap copy if same mnemonic is defined in docked dialog”: https://bugs.launchpad.net/inkscape/+bug/768103
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi All,
I had a quick look at using gdl_dock_item_new_with_stock() rather than using pixbuf icons... but I'm new to stock-items, so it's tricky for me. Jon mentioned previously that we already register our icons as stock, but I can't seem to find where or how this is done. As I understand it, we should register a GtkIconFactory somewhere, so that our icons can added to the list of stock icons. In main.cpp, we add our Icon theme to the default icon search path, but I don't see anything about stock icons... Am I missing something? Can someone point me in the right direction?
Thanks,
AV
On 13 June 2011 19:23, Josh Andler <scislac@...400...> wrote:
All those BUGS not branches... with the external-gdl branch.
On Mon, Jun 13, 2011 at 11:22 AM, Josh Andler <scislac@...400...> wrote:
Tested and commented on all those branches.
On Mon, Jun 13, 2011 at 2:16 AM, ~suv <suv-sf@...58...> wrote:
On 12/6/11 21:37, Alex Valavanis wrote:
- Docked dialogs no longer grab keyboard focus... this is a bit
annoying, because you cannot tab-select input fields.
On 13/6/11 10:30, Alex Valavanis wrote:
@Josh - The upstream developer sounded very positive about accepting some/all of our changes (https://bugzilla.gnome.org/show_bug.cgi?id=652248). I guess the focus-switching is the most critical issue... we can live without icons, and as per the preceding discussion, it should be possible just to use the existing API if we decide we want to. I have asked Johannes from gdl if he would be happy to add this feature and if he can estimate an ETA.
The focus switching seems to trigger other UI/workflow issues in Inkscape's GUI though. I haven't built the branch with the external gdl yet - to be able to compare - but will provide some links to the bug tracker [1]: several reports (+duplicates) are about keyboard shortcuts trapped by docked dialogs - failing without explicitly moving the focus back to the canvas or even causing status changes in the current document (for example making 'root' the current drawing level even though 'root' is normally not accessible from within the GUI).
Before committing changes upstream, maybe those issues can be investigated if they are due to local changes in gdl, possibly limited to ported platforms only or need to be addressed elsewhere in Inkscape's code?
~suv
[1] some (IMHO) related reports:
Bug #201203 in Inkscape: “focus issues when using docked palettes”: https://bugs.launchpad.net/inkscape/+bug/201203
Bug #505225 in Inkscape: “Layer text box popup”: https://bugs.launchpad.net/inkscape/+bug/505225
Bug #666512 in Inkscape: “Cannot use keyboard to move layer up/down”: https://bugs.launchpad.net/inkscape/+bug/666512
Bug #768103 in Inkscape: “Alt+B does not create a bitmap copy if same mnemonic is defined in docked dialog”: https://bugs.launchpad.net/inkscape/+bug/768103
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Jul 23, 2011, at 8:20 AM, Alex Valavanis wrote:
I had a quick look at using gdl_dock_item_new_with_stock() rather than using pixbuf icons... but I'm new to stock-items, so it's tricky for me. Jon mentioned previously that we already register our icons as stock, but I can't seem to find where or how this is done. As I understand it, we should register a GtkIconFactory somewhere, so that our icons can added to the list of stock icons. In main.cpp, we add our Icon theme to the default icon search path, but I don't see anything about stock icons... Am I
Yes,
Most of that code has been working in src/icon.cpp. Over time other people have removed parts of our icon code as 'redundant', but most should be back now. One thing we want is that our icons take last priority when the system is loading. Also the stock items use one 'icon '-ish thing with several sizes and/or variants in them. I know that when the code was written, it all functioned correctly. I have not tested that aspect recently, though. Let me know if it had gotten broken again.
Thanks.
Hi Jon,
Thanks for the quick reply. I have had a look at src/widgets/icon.cpp, and I still don't see any IconFactory code. In fact, grep returns no hits at all in src/. I found a commit in the bzr log that appears to have removed the functionality.[1] Any thoughts?
AV
[1] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/7779#src/w...
On 23 July 2011 17:06, Jon Cruz <jon@...18...> wrote:
On Jul 23, 2011, at 8:20 AM, Alex Valavanis wrote:
I had a quick look at using gdl_dock_item_new_with_stock() rather than using pixbuf icons... but I'm new to stock-items, so it's tricky for me. Jon mentioned previously that we already register our icons as stock, but I can't seem to find where or how this is done. As I understand it, we should register a GtkIconFactory somewhere, so that our icons can added to the list of stock icons. In main.cpp, we add our Icon theme to the default icon search path, but I don't see anything about stock icons... Am I
Yes,
Most of that code has been working in src/icon.cpp. Over time other people have removed parts of our icon code as 'redundant', but most should be back now. One thing we want is that our icons take last priority when the system is loading. Also the stock items use one 'icon '-ish thing with several sizes and/or variants in them. I know that when the code was written, it all functioned correctly. I have not tested that aspect recently, though. Let me know if it had gotten broken again.
Thanks.
On Jul 23, 2011, at 1:25 PM, Alex Valavanis wrote:
Hi Jon,
Thanks for the quick reply. I have had a look at src/widgets/icon.cpp, and I still don't see any IconFactory code. In fact, grep returns no hits at all in src/. I found a commit in the bzr log that appears to have removed the functionality.[1] Any thoughts?
AV
[1] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/7779#src/w...
AHA! That explains it.
Looking at that, I recall that others had complained about the stock usage, and that it had been replaced with the theme-able named icons.
The problem is that libgdl is using the older approach after all, so we will need to restore things back up. Of course, some testing will be needed, but GDL does seem to be the reason to restore stock.
On 23/07/11 21:48, Jon Cruz wrote:
Looking at that, I recall that others had complained about the stock usage, and that it had been replaced with the theme-able named icons.
The problem is that libgdl is using the older approach after all, so we will need to restore things back up. Of course, some testing will be needed, but GDL does seem to be the reason to restore stock
It's been a while since I last hacked on gdl, but a couple of years ago I worked on that code for Lumiera. I was working on the code that allows custom widgets (e.g. drop down selector ala blender) to be placed in the grip.
As you say gdl does use stock icons, but I'm sure everyone would welcome it being modernized to support whatever new scheme has replaced them.
Joel
2011/7/24 Joel Holdsworth <joel@...1709...>:
As you say gdl does use stock icons, but I'm sure everyone would welcome it being modernized to support whatever new scheme has replaced them.
+1 It's better to add code to use themable icons to GDL, rather than using the old stock items mechanism, which is going to be removed anyway after GDL gets this functionality.
By the way, I have an idea: since we create an icon disk cache anyway now, why not create the cache in a freedesktop.org-compliant icon theme layout and then simply use gtk_icon_theme_append_search_path() on it? This would make roughly 60% of the code in icon.cpp redundant, as we could use Gtk::Image instead of SPIcon.
Regards, Krzysztof
On Jul 24, 2011, at 3:24 PM, Krzysztof Kosiński wrote:
2011/7/24 Joel Holdsworth <joel@...1709...>:
As you say gdl does use stock icons, but I'm sure everyone would welcome it being modernized to support whatever new scheme has replaced them.
+1 It's better to add code to use themable icons to GDL, rather than using the old stock items mechanism, which is going to be removed anyway after GDL gets this functionality.
By the way, I have an idea: since we create an icon disk cache anyway now, why not create the cache in a freedesktop.org-compliant icon theme layout and then simply use gtk_icon_theme_append_search_path() on it? This would make roughly 60% of the code in icon.cpp redundant, as we could use Gtk::Image instead of SPIcon.
That wont work.
It breaks the load order. We want to have our internally generated icons have last priority, not first.
*However* the Gtk::Image vs SPIcon issue is a slightly different one. They are not tied one-to-one.
W dniu 25 lipca 2011 02:22 użytkownik Jon Cruz <jon@...18...> napisał:
That wont work. It breaks the load order. We want to have our internally generated icons have last priority, not first.
No, it will definitely not break the load order. There are two functions. gtk_icon_theme_append_search_path() - this will add the specified directory as the last one searched, and is the one I suggested. gtk_icon_theme_prepend_search_path() - this would add the cache directory as the first one searched.
Regards, Krzysztof
On Jul 24, 2011, at 6:04 PM, Krzysztof Kosiński wrote:
W dniu 25 lipca 2011 02:22 użytkownik Jon Cruz <jon@...18...> napisał:
That wont work. It breaks the load order. We want to have our internally generated icons have last priority, not first.
No, it will definitely not break the load order. There are two functions. gtk_icon_theme_append_search_path() - this will add the specified directory as the last one searched, and is the one I suggested. gtk_icon_theme_prepend_search_path() - this would add the cache directory as the first one searched.
Have you tested them?
Last time I checked, there were complications once one added user-defined icons. It is possible they have fixed things since then, but at the time the various combinations were tested and vetted for suitability.
Alex,
I just built on oneiric, the Tab issue is definitely not fun... as for the icons, it's purely cosmetic and not a blocker by any means. Is there any indication on if the tabbing patch could be accepted and released in time for the fall distro releases?
Cheers, Josh
2011/6/12 Krzysztof Kosiński <tweenk.pl@...400...>
2011/6/13 Jon Cruz <jon@...18...>:
Among other things you end up with a single-sized bitmap that is used
regardless of situation and user preferences.
When you use gtk_image_set_from_icon_name the optimal size present in the theme is picked, so this functionality is not unique to stock items (also see below).
It is much more flexible to use a custom stock icon.
GtkImage can display stock items. Are you arguing against using gtk_image_set_from_pixbuf (which I agree is not the best idea, but we can use it temporarily) or against exposing GtkImage as a property?
Regards, Krzysztof
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Just FYI, it does not compile on win32.
Make error line 303: problem compiling: In file included from src/widgets/../ui/ dialog/dock-behavior.h:22:0, from src/widgets/../ui/dialog/dialog.h:19, from src/widgets/../spray-context.h:24, from src/widgets/toolbox.cpp:93: src/ui/widget/dock-item.h:22:21: fatal error: gdl/gdl.h: No such file or directory compilation terminated.
Also, is it possible to run multiple jobs with btool? I haven't tried -j#, but am wondering.
Cheers, Josh
On Sun, Jun 12, 2011 at 3:18 PM, Jon Cruz <jon@...18...> wrote:
On Jun 12, 2011, at 2:53 PM, Krzysztof Kosiński wrote:
2011/6/12 Alex Valavanis <valavanisalex@...400...>:
Hi Josh,
The small icons that appear in the handle of our docked dialogs are all rendered in this manner as far as I can tell. At the moment, upstream gdl only allows dialogs to be created either with no icon in the handle at all [gdl_dock_item_new()] or with a stock icon in the handle [gdl_dock_item_new_with_stock()]. We have added a new option [gdl_dock_item_new_with_pixbuf_icon()] that allows a pixbuf icon to be used in the handle.
I think the best solution would be to expose the GtkImage widget that displays the dock icon as a property, so that we can use gtk_image_set_from_pixbuf or gtk_image_set_from_icon_name on it.
That might not be the best.
Among other things you end up with a single-sized bitmap that is used regardless of situation and user preferences. It is much more flexible to use a custom stock icon. Since Inkscape hooks itself in as a provider of stock icons, it can supply any as needed, and with dynamic sizing.
Work-arounds include rendering and grabbing a pixmap early in the process, but that has led to many bugs, including some significant crashing in many apps (not just Inkscape). But that a proper solution fixes crashing without need for work-around code, and also provides proper dynamic sizing, makes it a much better choice.
Regardless, gtk_image_set_from_pixbuf should be avoided.
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Jun 12, 2011, at 12:37 PM, Alex Valavanis wrote:
The small icons that appear in the handle of our docked dialogs are all rendered in this manner as far as I can tell. At the moment, upstream gdl only allows dialogs to be created either with no icon in the handle at all [gdl_dock_item_new()] or with a stock icon in the handle [gdl_dock_item_new_with_stock()]. We have added a new option [gdl_dock_item_new_with_pixbuf_icon()] that allows a pixbuf icon to be used in the handle.
But one interesting factor is that Inkscape registers itself as a stock icon source and most likely can supply those.
On Sun, Jun 12, 2011 at 6:10 PM, Alex Valavanis wrote:
I see three options for fixing the problem:
- Build against external GDL right away --- This should be easy to
do, but we'd lose our changes for a while. However, I'm not sure any of the changes represent essential Inkscape design features and we'd be able to reimplement them when they appear in the upstream API.
I'd vote for this one.
Alexandre Prokoudine http://libregraphicsworld.org
participants (7)
-
Alex Valavanis -
Alexandre Prokoudine -
Joel Holdsworth -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
~suv