I just wanted to say...
We should not be coding dialogs any more.
Instead we need to keep in mind breaking things down and making them reusable. One thing would be to avoid subclassing Gtk::Dialog. Instead we should have things more generic, and come up with a generic class based on Gtk::Container. These composit widgets could then be wrapped in a Gtk::Dialog for convenience, but then they could also be dropped into tabbed pages of a notebook, set vertically in a single window, etc.
And then in our code, we should try to avoid the physical concept of "pop up the style dialog", and instead replace it with the logical concept of "present the style chooser to the user". That's a very subtle difference, but can help in lots of areas.
Also... are there any other components we should come up with? Right of hand I can think of one in the 'Icon Preview' dialog I'm working on. It probably needs an document chooser, much like on the GIMP's layer dialog. However, others might need this too, so I was thinking it would be nice to have it generic and as reusable as the 'current color widget'. Anything else?
a gradient editing widget, ala gimp. Basically need the gradient preview widget extended to have markers indicating stop positions, preferably with the ability to process drag operations on those handles and click operations between them (although bulia may well have plans for gradient editing that makes this unnecessary)
could use a table/list widget that displays previews of markers or patterns. could probably be leveraged for a clipart library ui too.
cant think of anything else off the top of my head.
Cheers
John
--- "Jon A. Cruz" <jon@...18...> wrote:
I just wanted to say...
We should not be coding dialogs any more.
Instead we need to keep in mind breaking things down and making them reusable. One thing would be to avoid subclassing Gtk::Dialog. Instead we should have things more generic, and come up with a generic class based on Gtk::Container. These composit widgets could then be wrapped in a Gtk::Dialog for convenience, but then they could also be dropped into tabbed pages of a notebook, set vertically in a single window, etc.
And then in our code, we should try to avoid the physical concept of "pop up the style dialog", and instead replace it with the logical concept of "present the style chooser to the user". That's a very subtle difference, but can help in lots of areas.
Also... are there any other components we should come up with? Right of hand I can think of one in the 'Icon Preview' dialog I'm working on. It probably needs an document chooser, much like on the GIMP's layer dialog. However, others might need this too, so I was thinking it would be nice to have it generic and as reusable as the 'current color widget'. Anything else?
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
__________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
On Wed, 09 Mar 2005 09:27:11 -0800, Jon A. Cruz <jon@...18...> wrote:
Also... are there any other components we should come up with? Right of hand I can think of one in the 'Icon Preview' dialog I'm working on. It probably needs an document chooser, much like on the GIMP's layer dialog.
No. Our preferred approach is simpler: Just work with the document in the currently active window. That's the way most dialogs work now, and it's much more convenient.
bulia byak wrote:
No. Our preferred approach is simpler: Just work with the document in the currently active window. That's the way most dialogs work now, and it's much more convenient.
Ahhh...
But that's why the Gimp's document cooser has a toggle button for "Auto" that's on by default.
:-)
Usually that's what one wants. But if something different is needed, the user has the choice to override. And with a very simple UI too.
On Wed, 09 Mar 2005 10:01:12 -0800, Jon A. Cruz <jon@...18...> wrote:
But that's why the Gimp's document cooser has a toggle button for "Auto" that's on by default.
:-)
Usually that's what one wants. But if something different is needed, the user has the choice to override. And with a very simple UI too.
I don't think overriding is worth the trouble of coding it, it seems to me it just adds clutter and makes the interface less obvious.
On Wed, 9 Mar 2005, bulia byak wrote:
Date: Wed, 9 Mar 2005 14:06:41 -0400 From: bulia byak <buliabyak@...400...> To: Jon A. Cruz <jon@...18...> Cc: Inkscape devel list inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] No more dialogs!!!
On Wed, 09 Mar 2005 10:01:12 -0800, Jon A. Cruz <jon@...18...> wrote:
But that's why the Gimp's document cooser has a toggle button for "Auto" that's on by default.
There is also an option "Show Image Menu" which allows you to get rid of it entirely (my preferred option).
Usually that's what one wants. But if something different is needed, the user has the choice to override. And with a very simple UI too.
I don't think overriding is worth the trouble of coding it, it seems to me it just adds clutter and makes the interface less obvious.
I want to shout "me too" and agree with Bulia for a change, but at the same time I have to make an effort to try and say something insightful.
I really dont think it fits in with the Single Document Interface paradigm to be worrying about anything other than the current document. (There might be some value to keeping things consistant with the GNU Image Manipulation Program but I think that is whole other question and doesn't really apply in this case.)
- Alan H.
participants (5)
-
unknown＠example.com -
Alan Horkan -
bulia byak -
John Cliff -
Jon A. Cruz