Fabien,
These are great ideas!
Actually, I think that if we want to significantly increase the
complexity of vTcl, we will need some sort of object-oriented
way of doing things. It will get more and more complicated to
handle global variables and global arrays.
I've seen there is an extension like Itcl but entirely written in
Tcl instead of having to rely on additional loadable libraries.
I don't know about the efficiency, though.
About Wizards. Maybe you could base this on Iwidgets. They have a
widget called "mainwindow" that has a menu bar, 2 toolbars,
a status bar, and a client area. Problem is, you need to set all the
parameters programmatically. A wizard would be great in that case,
and you could choose to include standard copy/cut/paste menu items,
file open/save support, an about box, etc. like SDI with Microsoft
Visual C++ (except you don't have to throw away 600 bucks).
Iwidgets even has a tabbed notebook too.
Among other ideas, I would love to see in-place localization
capabilities. Because end-user projects change their dialog boxes
and UI at such a speed, there is no way to freeze the UI for
translation. There should be a way of selecting the language and
voila, your dialog boxes will redisplay in German or French. But you
would not have to do 1 copy of your script for each language. Instead,
each string would have some special encoding for example:
[localized -enu "This is a text" -fra "Ceci est un texte"]. Or, use
the message catalog in Tcl/Tk 8.2 ?
Anyway, let's go back to work... on vTcl.
Christian
Fabien COUTANT wrote:
>
> G'd day everyone... Sorry I'm so slow to answer.
>
> Many of you have E-mailed me asking for sources of my version. I have put up
> a small personal page at http://www.chez.com/fabiencoutant/ where you will
> find it with some comments along.
>
> So there seems to be great debate about features and howto about vtcl... let's
> throw in my 2c and have some brainstorming ;-P
>
> First try to summary what has been said in previous messages:
>
> - throw in every extension widget we can, but add autodetection mechanism plus
> option to disable it even if it's here.
>
> - pros and cons about whether vtcl itself should stick to core Tcl/Tk.
> Personally I would prefer it stays as is, since I want to continue to run it
> on VMS :-)
>
> - may need some ergonomic/behavior changes/corrections
>
> - new features needed: multi-file support, project manager, image manager,
> font manager, color manager,
>
> May I add and explain:
>
> - need some more versatile compound/component mechanism
>
> For me one of the biggest problems after multi-file support is the
> difficulty to build reusable components; compounds are ok for small things,
> but they are completely static and can't be parameterized. Here Tcl is the
> problem. Maybe we can extend the compound design with:
> - parameters that are filled in at instanciation,
> - dynamic behaviour with (for example) a context menu that allows to change
> the layout after creation.
> The typical thing I would like to be able to do is add a notebook widget of
> some sort, then add pages to it at will. Unless the notebook is a widget by
> itself, behaving exactly like others, it's impossible to do currently.
>
> - separate look and behaviour of widgets. It's currently hard to modify
> graphic settings of all widgets of some class (button, entry, ...) at once.
> The TK options mechanism would perhaps be ok if vtcl did not explicitly set
> these options on every created widget. What I have in mind is the ability to
> define CLASSES of widgets, that are basic widgets plus graphic settings, and
> use them as USUAL widgets but with only the ability to change behavior,
> content and variable attachments. Imagine you use always the same entry with
> some background, thin line, red cursor, other color settings and fixed
> width; now you've created 20 instances of it with copy-paste, to discover
> you want to change the blinking time. A pain to correct (I've done that
> once), but not if all instances refer to the same class for which you can
> change attributes.
>
> Again it's a matter of object programming, and TCL is the problem. Maybe
> iTcl or MegaWidget could help, I don't know them enough.
>
> - wizards: interactive dialog sequences that build complex interfaces (not
> just instanciate a single widget or compound) with the help of a few
> questions. The main one I have in mind would be to build database
> interfaces: log to database, choose table, choose the fields to display, et
> hop, a table viewer; choose another set of fields, and make an input form.
>
> Maybe I'm dreaming ! Sure however something can be useful...
>
> About other questions:
>
> Christian's work does not collide with mine, except he started from version
> 1.2.0 and I started from 1.3.0. We share some plans however... But for me,
> it's ok and we can work in parallel.
>
> I'm voluntary for the project manager, possibly completing multi-file support
> at the same time (since I've started it !) -- oh BTW I've put a screenshot of
> the current project manager window on my page.
>
> For a tabbed preferences dialog, I can offer my pure-Tcl notebook widget, then
> anyone can take this on since it should not be a complex work. The file for
> the widget is in my sources, though not yet loaded in vtcl.
>
> --
> Best regards,
> Fabien.
>
> _______________________________________________
> vtcl-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/mailman/listinfo/vtcl-user
_______________________________________________
vtcl-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/vtcl-user
