Re: [Flamerobin-devel] Insert row dialog

[Michael H. <mg...@gm...>]

Hi Milan,

Milan Babuskov wrote:

> - The dialog should be at most 80% of the screen height. To work
> around this we could:
> 
> 1. make dialog scrollable. IIRC, I did write about this as well at the
> time, as I'm not sure whether it is a good idea. I haven't seen many
> applications where dialogs containing regular controls scroll.
> 
> OR
> 
> 2. If there are too many columns and 80% limit is reached, the dialog
> is separated into multiple 'parts'. These 'parts' can be:
> 
> a. tabs (wxNotebook or whatever)
> b. wizard like interface with back/next buttons
> c. something else?

I don't think that creating several controls for each column is ever 
going to work, which ever way they are presented to the user.  Some 
windowing system will not even be able to create that many controls, 
wxWidgets sizing is not going to cope with them either.  That's ignoring 
the fact that spreading them over several pages is probably not going to 
improve the user expeience.

> - executing another query
> - closing the transaction

I think they can be handled the same as clearing the data grid.

> - navigating to a different row

This might be harder; I remember the discussion about wxGrid vs. wxSheet 
where John Labenski cited the problems of wxGrid regarding vetoing of 
grid movement as one of the reasons for writing wxSheet.  But we could 
follow Nando's advise and disable only the parent ExecuteSqlFrame.  That 
would take care of all of them.

> Does this also imply you've given up on the 'rewrite' idea you had
> before?

No, not at all.  This effort has languished for some time, meaning I 
think about it now and then, but haven't written any code for some 
months now.
The problem is that whenever I need FlameRobin for my everyday work I 
need a working system.  A rewrite will take time to get into usable 
state.  Especially since it's a hobbyist side project when I haven't got 
much time as it is.
But I have some things I need feedback on, so I will probably post about 
some of them here, sooner or later.  Rewriting from scratch is not the 
best of ideas anyway, but without a reality check from the outside every 
now and then it's even worse.

> I agree. However, it is sometimes impossible until you have some code
> as basis for discussion. If you go through the initial 'editable grid'
> discussions related to insert dialog, you'll see that in the end we
> reached the point of 'code it and see how it looks like' and that's
> exactly what I did.

I know.  Please don't take my comments the wrong way, it's just that I 
really really needed the editing functionality lately, and the dialog 
let me down.

> I do admit there was 'run for features' before, but since 0.7.6 I'm 
> doing my best to avoid that. However, designing and coding a feature 
> you don't use (as was case for me and editable grid) is hard as you 
> can't see the end goal clearly. I don't want to sound like looking
> for an excuse, but sometimes I wish there's more feedback when new 
> features are discussed.

Amen to that.

> Or even the old ones. For example: the advanced search dialog which I
> use extensively - we got no feedback from users (and one from you 
> saying it that layout should be improved). This means that either
> they think it's 'the right thing' or they are not using it at all. In
> both cases, I see no need for improving it until we get some feedback
> saying what to change.

I really never use it, so I have no reason to work on it either.  I have 
worked on dialogs and frames I rarely (event monitor) or never (field 
properties, trigger wizard) use, though.

Still, both AdvancedSearchFrame and DataGeneratorFrame could use some 
layout work.

> Agreed. As I wrote above, I stopped running for the 1.0 somewhere 
> after 0.7.6 as all the features I needed were completed. I know that 
> many features in current FR are only proof-of-concept and need to be 
> worked on before we can even call it Beta software. This is why I'm 
> not pushing forward the idea of 0.9.0 release, as I know there's a
> lot of work to be done to get us there. We have all the features, but
> many need polishing.

Agreed.  But I guess we would simply need to be more people working on 
it.  As it is I doubt FlameRobin will ever be polished.

> I would be very sorry if you'd leave the project.

No, that's not my intention.  After all I need FlameRobin for my work. 
But I will probably concentrate on bugs when I encounter them, or work 
on features I need, but stop treating FR as a hobby project.  The 
current code base, that is.

> As for OS X, I only managed to grasp that problem lies in menu 
> handling. Is there anything else beside that that makes it painful?

Firebird on Mac OS X is a little painful sometimes in general.  There 
still is no Universal Build of a Server, nor a client-only install. 
That's like actively discouraging Mac developers to use Firebird.

But to get back on-topic, what IMHO really needs to be done to improve 
FlameRobin on Mac OS X is the following:

1. All command IDs should be moved from frames and dialogs to 
CommandIds.h file.  wxWidgets standard ids need to be used if available, 
all others should be unified as much as possible.
2. ExecuteSqlFrame menu needs to be removed on Mac.
3. MainFrame menu needs to be a global menu on Mac, containing all 
commands in a sensible layout.  So maybe we would need another top-level 
menu "Statement" or something, which would contain commands to start, 
commit and rollback transactions, set transaction properties, prepare 
and execute statements, ...  This one would replace the Query menu in 
ExecuteSqlFrame.  The Grid menu would go completely, the commands moved 
to File, Edit and View menus.
4. Some menu commands need to be enabled depending on the focused 
control (save, cut, copy, paste, ...), while others need to be enabled 
depending on some other state (execute, commit, rollback, ...).

I guess you could compare a Mac program to a MDI program on Windows, 
where you have one menu in the main window, but have different types of 
MDI children, each with (partially) different applicable commands. 
Depending on the active MDI child some commands are available, and some 
others are not.  For GTK the current design with a menu in each frame 
that needs it is obviously better.  Maybe there's a way to code FR so 
that it uses different program designs on different platforms, haven't 
thought much about that.  But the changes would hopefully make FR work 
better on all platforms.  Stuff like saving log control contents, 
support for command accelerators (like Ctr+C for copying grid contents) 
and so on would benefit them all.

Thanks for your reply.  I hope you didn't take my insert row dialog 
criticisms personally, they weren't intended to be.  Maybe I would be 
less frustrated if we were more people working on FR, so progress was 
more visible.  Maybe I just need a short break.  The next time I need 
the dialog I will probably look into a redesign using wxGrid.

Thanks

-- 
Michael Hieke