Re: Tabbed Usage



On Sun, 2007-04-15 at 01:18 -0500, Patrick Hallinan wrote:


On 4/14/07, Lars Clausen <lars raeder dk> wrote:
        On Fri, 2007-04-13 at 14:11 -0500, Patrick Hallinan wrote:
        > Lars said:
        >
        > >> + Tabbed organisation of open diagrams (Like Firefox's
        pages) and the
        > >> toolbox window all being in one consolidated environment.
        If this is 
        > >> possible already can you please explain, how can I do
        this?
        >
        >
        > > That is not currently possible, I'm afraid.  I'm loath to
        try to implement
        > > such a thing myself, so it'll have to be based on what GTK
        offers.  What 
        > > I'd like is something like KDE's draggable subwindows, but
        possibly a
        >
        > > GtkNoteBook and the toolbox together in a window would be
        an alternative.
        > > I'd like it to be user configurable in some other way than
        through 
        > > preferences, but that may be a little much.  Maybe the
        preferences setting
        >
        > > should be "Gimp-like UI" (menu on right mouse, loose
        windows) vs.
        > > non-Gimp-like (menubar, one window with tabs). 
        >
        > I was happy to find this.  I was thinking of something along
        these
        > lines.  I just started looking at the code.  If someone
        could suggest
        > an approach I could start working on this.  I was thinking
        of starting 
        > with a simple glade project and trying to make the Dia
        pieces loadable
        > widgets but maybe it makes more sense to create an alternate
        UI that's
        > integrated in the project.
        
        Please don't use Glade.  The one piece of Glade-based UI we
        have is an 
        unmaintainable mess.  Besides, this functionality will be
        spread out
        over the program to a large degree.
        
        > It looks like I would start hacking in app_init():
        >
        > void app_init(int argc, char** argv) { 
        > /* ... */
        >
        >   prefs_init();
        >
        >   if (dia_is_interactive) {
        >     if( dia_gimp_like_ui_interface_selected )
        >
        >       init_gimp_like_ui();
        >     else
        >       init_non_gimp_like_ui(); 
        >
        >
        > Of course I don't have a clue about what kind of changes
        this would entail.
        
        We already have a prefs setting use_menu_bar that determines
        if the
        diagram window is in the right mouse button or a regular menu
        bar.  I 
        suggest you start by encapsulating that in a function
        gimp_like_ui(), so
        it is isolated.  Then you'll also see where it gets used.
        
        The current use_menu_bar setting is for new views;
        gimp/no-gimp UI
        should be per-invocation, so for consistency new views should
        get the 
        menu bar setting from startup, not from the newest
        preferences, which
        may have changed; the gimp_like_ui() function can hide that
        difference.
        At the same time, the preference should move away from the new
        view
        section in preferences.
        
        At that point, new functionality would be easy to add, that's
        where your
        above if-sentence comes in.  interface.c has most of the
        window setup
        stuff.  Are you planning to do some kind of "docking" like
        newer gimp 
        versions, where things like layers dialog can fit in the same
        window as
        the toolbox?

I guess I was thinking of expanding the toolbox window to encompass a
notebook for diagram windows and have the diagram window menu
integrated with the toolbox menu.  I spent a few hours today just
poking through the code.  I think I want to build out some
documentation of the current architecture/object interactions before I
do much else.  I wasn't thinking at all about "docked" components.
Just about an integrated interface that contained all the pieces in a
single window.  

That'd probably be easier.  What were you thinking of doing for the
layers dialog?

Hadn't thought about the two sets of menus.  I guess we'd need a third
"File" menu that's a combination of the two current ones.  Fortunately,
that should be easy with GtkAction.

I don't understand why you would want the use_menubar preference to be
locked in at startup.  It seems like something that would not be hard
to change even in a window that was already up.  

When it changes to be gimplike_ui, changing it on the fly would mean
assembling/disassembling the windows, changing the menubars and other
stuff.  I'd rather have working code that can only change at startup
than unfinished/messy code that can change any time.  Once we've ironed
out how the two interfaces differ and have that working, we can look
into changing on the fly.  

-Lars




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]