regarding this native dialogue thing: - the gtk dialogues write some configuration data. - this will then create troubles for the USB stick version of win32 - because the portable apps have to remove/recreate all new/changed data in the host directory system To be more verbose: for me to return to gtk dialogues is a no-go.

HTH,

Adib.

On Mon, Nov 8, 2010 at 11:41 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:

On 2010-11-07 23:34, Krzysztof Kosiński wrote:

...

Please tell me how do you feel about removing the following code:

• dom/
• pedro/
• jabber_whiteboard/
• Scripts dialog
• Java binding stuff
• one of the Find dialogs
• native Windows file dialogs

As you may have noticed the last item on the list is subject of the debate, as for the rest: be my guest! Any dead or nearly dead code we remove will generally lead to a lighter, more stable and more maintainable Inkscape! I'd also love to eliminate one of pixblock-transform and nr-compose-transform, but perhaps some of the GSoC Cairoification work has taken care of this already.

...

Rationale:

• dom/ and Java binding are obsolete, the DBus binding should be used

instead. For high performance applications there could be a binary plugin API, but I'd prefer to do that once the internal APIs are sane (right now they are far from it).

Does the DBus binding work on Windows btw? If so, is there somewhere where I can read up on how to use it?

...

• pedro/ and jabber_whiteboard/ contain Inkboard stuff which doesn't work.
• The purpose of the script dialog evades me. To what extent does the

scripting capability work?

• There are two Find dialogs, one of them is disabled with a notice in

the code encouraging to test it. This should be finally resolved.

• Native file dialogs are a maintainability nightmare and aren't that

much better than GTK dialogs; they are the reason I went for the "embed / link" popup hack for images instead of putting the checkbox in the import dialog.

I seem to remember that I also didn't like the GTK dialog much, but if you'd like to argue that Inkscape is not the proper place to fix it then I'd tend to agree. So personally I wouldn't be against removing the native dialog code from Inkscape. If we don't like it, lets try to fix it in GTK, and not make our code more complicated. (If you'd like to be on the safe side, make the native dialog optional for now, with a hidden switch or even a compile time option, if that's easy to do, then we can have some transition time.)

---

The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2010/11/8 Krzysztof Kosiński <tweenk.pl@...400...>:

1. We don't have many experienced Windows developers, and tying up

this scarce resource with maintaining what amounts to eye candy doesn't seem to be very wise to me. 2. Creates potential for platform specific bugs, e.g. https://bugs.launchpad.net/inkscape/+bug/285267

But file dialogs are definitely not where things are happening in Inkscape, so this burden is relatively small. It's not at all like maintaining two renderers :)

3. Having 2 versions of the dialog means that anyone who wants to add

any feature to the dialogs must be proficient both in Windows API and in GTK.

We better avoid adding too much of our stuff to these dialogs anyway. They are traditionally the responsibility of the OS or widget library, not ours. We should strive to keep our contact area with them to the absolute minimum.

2010/11/8 Krzysztof Kosiński <tweenk.pl@...400...>:

I was referring to e.g. an extra checkbox in the import dialog that specifies whether the file is to be embedded or linked, or a button that brings up format options (which are currently shown as a popup). Adding extra controls is supported in both GTK and native Windows dialogs, and is a standard practice, but is more difficult in Windows API.

Now that I think about it, placing this checkbox into the file dialog seems a slightly weird UI choice. It mixes up different concerns. I know other software does it this way, but if I try to ignore the pressure of tradition and think about it objectively, it really seems to me that our current approach - one dialog to choose the file, the other to specify what to do with it - is more logical. For export, for example, it is normal to have two dialogs - one file dialog and one options dialog.