yact-dev Mailing List for Yet Another Case Tool
Status: Pre-Alpha
Brought to you by:
basic
Menu
▾
▴
yact-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(18) |
Mar
(14) |
Apr
(4) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Daniel B. <ba...@we...> - 2000-06-12 11:09:20
|
Hi all, I've just uploaded two file releases to SourceForge, one for Qbf and one for Yact. Both are Linux binaries, and include Doxygen documentation. The major improvement in Qbf is that the XML reader/writer stuff seems to work quite well now, and is begin used by the "Open" and "Save As" actions in the diagram editor in Yact. There aren't a whole lotta attributes that are saved yet though, but it's a start. Have fun with it! :) /Basic |
|
From: Daniel B. <ba...@we...> - 2000-05-20 21:16:09
|
Hi, On Mon, Mar 13, 2000 at 08:54:22PM -0800, Marius Sundbakken wrote: > I think we should add a YNullable interface (or similar): I haven't found a good place in Yact for it yet, but I do have a QbXmlNullNode in the XML parser in Qb. A few if's disappeared. :) /Basic |
|
From: Marius S. <ma...@fi...> - 2000-04-25 16:34:16
|
> > But I still stand by it. Getting rid of those 'if not null' statements > > makes the code nicer, the flow simpler, and the program more > > stable. Stable is the word, not necessarily correct. But at least stable. > >Interesting... Previously I've always been the one who has been pushing >for more theoretical solutions, and you're the one holding back. Now >it's the exact opposite. Guess you've been studying too much. ;) Hm, really? Well, I sure have been studying too much, but it never struck me that it may have affected my C++/OO thinking (what I study is not really related), but you may be right. >I think "use with care" is a good phrase to have in mind, not only for >null pointers. True. General wisdom :-) - Marius |
|
From: Daniel B. <ba...@we...> - 2000-04-24 08:50:34
|
On Wed, Apr 12, 2000 at 08:06:56PM -0700, Marius Sundbakken wrote: > At 09:44 PM 4/12/00 +0200, Daniel Brahneborg wrote: > >On Mon, Mar 13, 2000 at 08:54:22PM -0800, Marius Sundbakken wrote: > > Gee... my original post is almost one month old... :-) I wanted to read it carefully. ;) (This time it only took me two weeks... I'm getting quicker!) > >Sometimes null objects are ok though, and when that situation comes up, > >I'll have no problem introducing YNull(able). I don't see much use for > >it right now, though. Do you (apart from that bug below)? > > Well, again, maybe not so much now, but it fell into my mind and I quickly > posted it to the list so that we won't forget :-) Postings are good, and discussions are good. :) > But I still stand by it. Getting rid of those 'if not null' statements > makes the code nicer, the flow simpler, and the program more > stable. Stable is the word, not necessarily correct. But at least stable. Of course, that's what all the YInputHandler classes are there for. Interesting... Previously I've always been the one who has been pushing for more theoretical solutions, and you're the one holding back. Now it's the exact opposite. Guess you've been studying too much. ;) I think "use with care" is a good phrase to have in mind, not only for null pointers. /Basic |
|
From: Marius S. <ma...@fi...> - 2000-04-13 03:14:50
|
At 09:44 PM 4/12/00 +0200, Daniel Brahneborg wrote: >On Mon, Mar 13, 2000 at 08:54:22PM -0800, Marius Sundbakken wrote: Gee... my original post is almost one month old... :-) > > I think we should add a YNullable interface (or similar): > > [..] > > Let's get rid of as many "if pointer is not null" statements as > > possible. > >Well, there aren't that many of those there, actually. Maybe not now. > > I think this will make Yact a lot more stable (the risk of > > coredumping is greatly reduced) and code-flow in general will be much > > cleaner, prettier, and easier to read. No more of those annoying null > > pointer if's, and just go ahead and access the object directly. > >I'm not so sure about that. I kind of like core dumps, because they let >you know very quickly when something is wrong with the program. If some >method gets a null pointer when it shouldn't, the fix is to get rid of >that null pointer, not add a "if (!p) return". Now, that's why you have assert. Put assertions in and let the program crash when compiled in debug mode. However, when "release mode" is on, the nullable stuff comes into play. Don't crash the program for the user! >Sometimes null objects are ok though, and when that situation comes up, >I'll have no problem introducing YNull(able). I don't see much use for >it right now, though. Do you (apart from that bug below)? Well, again, maybe not so much now, but it fell into my mind and I quickly posted it to the list so that we won't forget :-) But I still stand by it. Getting rid of those 'if not null' statements makes the code nicer, the flow simpler, and the program more stable. Stable is the word, not necessarily correct. But at least stable. - Marius |
|
From: Daniel B. <ba...@we...> - 2000-04-12 20:08:37
|
On Mon, Mar 13, 2000 at 08:54:22PM -0800, Marius Sundbakken wrote: > I think we should add a YNullable interface (or similar): > [..] > Let's get rid of as many "if pointer is not null" statements as > possible. Well, there aren't that many of those there, actually. Lots of them disappeared when I pushed the gui logic to YInputHandler, and the ones that are left are mostly in the subclasses to that class. > I think this will make Yact a lot more stable (the risk of > coredumping is greatly reduced) and code-flow in general will be much > cleaner, prettier, and easier to read. No more of those annoying null > pointer if's, and just go ahead and access the object directly. I'm not so sure about that. I kind of like core dumps, because they let you know very quickly when something is wrong with the program. If some method gets a null pointer when it shouldn't, the fix is to get rid of that null pointer, not add a "if (!p) return". Sometimes null objects are ok though, and when that situation comes up, I'll have no problem introducing YNull(able). I don't see much use for it right now, though. Do you (apart from that bug below)? > You can already get Yact to crash by playing around with adding new > classes and adding inheritance and deleting them etc. I don't know > where the bug is exactly, but I bet it's a null pointer. I don't remember where it was, but it was a bad pointer somewhere... It's fixed now, anyway. :) /Basic |
|
From: Marius S. <ma...@fi...> - 2000-03-15 19:21:40
|
Hi Gerald, [cc'ed to Yact mailing list] >First the programming language is not totally fixed yet, for the moment >the first tests use java, but I am not a fundamentalist (but i >won't devellop under windows with Microsoft APIs) OK. Yact, as you know, uses C++ and the Qt toolkit. It's being written for Linux, but other UNIX flavors should work as well without too much of a hassle. In fact, it may even compile on Windows as well. >My main goal is to produce the code generator (for the moment >input XMI output C, C++, Java), because a lot of projects are >currently working on graphical interface and so on... Yes, you're right. Several UML tool projects have popped up lately, although almost all of them after Yact :-) I've been in touch with the the GNUM author (http://sourceforge.net/project/?group_id=2566) and we talked about the repository format. Nothing is decided, but we have plans on using UXF (http://www.yy.ics.keio.ac.jp/~suzuki/project/uxf/) as it is easier. We've also discussed CDIF. XMI has, of course, also been discussed, but we fear that it is too complicated. Yact is, of course, designed so that it could eventually create all these formats. It's just a question which of them we should make first. But you'll have to write a parser for XMI if you're going to use it, and so, I guess a general enough parser would be useable for Yact to load stored files as well. If so, Gnage would have to be a library or something. But of course, that's up to you. Also, the GNUM author said that GNUM neither is going to user interface centric. I've not been in touch with the Dachshund authors as their project seems to very similar to Yact, that is, GUI centered. Unfortunately, they are using a different toolkit. However, they too need a repository and a parser of some kind... >I have some experiences on code generators (I am currently working >on code generators for Alcatel Space Industries), so >I think I know the needs and how to achieve them. This sounds very good! In the Yact team, Daniel knows the backbone structure of the tool (he has designed some before), Mike does all the makefile stuff, and I guess I'll mostly do GUI stuff (which I know). >Gnage as the code generator for Yact, and Yact as the XMI generator, >it's a good idea. Yes, indeed, this sound like a very good idea. No wasted effort on both implementing GUIs for example. >I do not know if I continue in Java, but it permit a great flexibility for >the configuration (for exemple user add dynamicaly classes) I'm not sure what you mean here. >I do not think that languages are so important, if we give users >a homogenous environnement, no need to have only C, C++ or java, >for example, my generetor is for the moment only called on command >line, so it can be easily used from a other tool. True. I didn't know that your project would be command line, so I was thinking more on source code level, and not on application level. Using command line tools from GUIs is OK, but it greatly restricts the possibilities of how to do the GUI. Things like progress bars, or good error handling is harder, if not impossible (depending on the tool). - Marius |
|
From: Marius S. <ma...@fi...> - 2000-03-14 04:59:21
|
I think we should add a YNullable interface (or similar):
class YNullable
{
bool isNullObject() = 0;
}
Let's get rid of as many "if pointer is not null" statements as
possible. I think this will make Yact a lot more stable (the risk of
coredumping is greatly reduced) and code-flow in general will be much
cleaner, prettier, and easier to read. No more of those annoying null
pointer if's, and just go ahead and access the object directly. If null
pointer have some meaning that makes them different from an object, then
use isNullObject(), where null classes return true, and other classes
return false.
You can already get Yact to crash by playing around with adding new classes
and adding inheritance and deleting them etc. I don't know where the bug
is exactly, but I bet it's a null pointer.
- Marius
|
|
From: Marius S. <ma...@fi...> - 2000-03-12 22:39:19
|
Firstly, look the subject line:
Re: [Qbf-dev] Re: [Yact-dev] Source code
Could you fix the prefix for the mailing lists as I suggested in some other
mail?
[GNU vs ANSI indention]
No, because with the current (GNU) indentation the visual difference
between a simple statement and a compound statement is minimal. ;)
Compare it with how you would write it using the comma operator:
if ()
a,
b,
c;
Sounds good... in theory (again). How often do you use the comma operator
like that? I never do.
Since the braces are part of the statement list, they should also get
the same indentation.
From a language design point of view, I guess braces is to be considered
as statements, just as other languages uses 'begin' and 'end'. Personally,
I don't find the code easier to read by considering them as such. In fact,
I use similar indention style in SML ('let', 'in', and 'end').
It is a matter of personal taste (religion?), I guess, so discussing it
will bear just as much fruit as discussing which of red and blue that is
the prettiest color.
> Btw: What tab size do you use?
4. I can add a little /* vim: ts=4 */ at the end of the files, if you
want. Emacs have something like that too, right?
I've set the tab size to 4 too, yes. I just wondered, because some of the
code looked a bit weird :-)
Be glad that I don't use tabsize *3*, I've seen that one too... :)
And I thought about switching to proportional fonts and using an indention
of 3.7 :-)
If you need to look at the documentation of a method I've written to
understand what it does, the code is bad and should be rewritten...
Well... It's faster to read an (abstract) comment than to look at the
(detailed) code.
> Also, I feel that it is much easier to "forget" the documentation when
> it's in the header file and thus become obsolete.
Good point. On the other hand, a header file is usually (but not
always) shorter than the cpp file, which makes it easier and faster to
browse and print.
What I find convenient about header files is that I can look at it and get
an overview of all a class provides. This is how I use them, and thus I
write them compactly, with no comments, and a function or variable on each
line. That way, I get an overview of pretty much all classes on one single
screen (I have a 19").
Also, I don't have a printer...
> As you know, better programming languages than C++ doesn't separate
> the interface from the code, and in such languages, you'll have
> everything in one place, i.e., the code and documentation will be
> together.
Haven't you gotten over Java, yet? ;)
:-)
I never liked Java. I was thinking of Eiffel.
> I try to get "rid of" the header files altogether (as far as possible)
> by placing the documentation in the code, and some day, also
> automatically update the header files as needed when I change
> something in the CPP file (such as adding a new function).
Unfortunately C++ has several things in the header file that can't be
put in the cpp file, which makes it kind of hard.
I don't mean to remove the header files. I just don't want to touch them
too much. Touch one and the compilator often goes ahead and recompiles
pretty much everything.
> >It also makes it easier to write interface classes, and they have no
> >.cpp file at all. ;)
>
> Well, I think that should be the exception rather than the rule.
Interfaces are good, and there will be more of them later. MI is ok, as
long as one doesn't have attributes in more than one class.
I'm not saying interfaces are bad. I'm saying that I don't think the
placement of documentation should be dependent on the rare cases where
there are only header files. I mean, I'm not for consistency just for
consistency's sake.
- Marius
|
|
From: Daniel B. <ba...@we...> - 2000-03-12 21:52:05
|
On Sun, Mar 12, 2000 at 08:27:17AM -0800, Marius Sundbakken wrote:
> A rubber band selector may seem irrelevant at this stage, but I feel that
> YOU have much of the design already figured out so I don't want to start
> hacking away at something that has to be dumped anyway. This way, a rubber
> band selector isn't such a waste of time after all (we have to have it
> anyway) :-)
Sounds like a good idea. Personally I'm working on the relationship
lines right now. I can now move around the ends of the lines, but I
can't get them to stick to another class.
> A pragmatic editor, such as Emacs, will of course do the "columnization"
> for you. >:->
So why are you arguing about it, if it isn't a problem? ;)
> OK then, now at least the variables have a sane indention style...
> only the rest to go :-) Such as the current GNU indention:
>
> if
> {
> }
>
> which is, of course, inferior to the ANSI indention:
>
> if
> {
> }
>
> :-))
No, because with the current (GNU) indentation the visual difference
between a simple statement and a compound statement is minimal. ;)
Compare it with how you would write it using the comma operator:
if ()
a,
b,
c;
Since the braces are part of the statement list, they should also get
the same indentation.
> Btw: What tab size do you use?
4. I can add a little /* vim: ts=4 */ at the end of the files, if you
want. Emacs have something like that too, right? Reason: Always using
a clean Tab for indentation makes it easy to increase or decrease the
indentation level, such as when you're putting an if-statement around a
block of code, without having to use an intelligent editor that can
switch between spaces and tabs. Also, tabsize 8 is too much.
Be glad that I don't use tabsize *3*, I've seen that one too... :)
> >For me it's a way of keeping apart the difference between the interface
> >and the documentation of _what_ the class does from the implementation
> >and _how_ and _why_ it does it. The header file is the "contract" of
> >the class, and as such, is a good place to put the documentation.
>
> This sounds good... in theory. For example, now as I'm learning the code,
> it would have been much easier to switch between the cpp files to get both
> code and documentation, instead of switching between *double* the amount of
> files.
If you need to look at the documentation of a method I've written to
understand what it does, the code is bad and should be rewritten...
You could also try Vim, it's pretty good at switching between files. ;)
> Also, I feel that it is much easier to "forget" the documentation when
> it's in the header file and thus become obsolete.
Good point. On the other hand, a header file is usually (but not
always) shorter than the cpp file, which makes it easier and faster to
browse and print.
> As you know, better programming languages than C++ doesn't separate
> the interface from the code, and in such languages, you'll have
> everything in one place, i.e., the code and documentation will be
> together.
Haven't you gotten over Java, yet? ;)
> I try to get "rid of" the header files altogether (as far as possible)
> by placing the documentation in the code, and some day, also
> automatically update the header files as needed when I change
> something in the CPP file (such as adding a new function).
Unfortunately C++ has several things in the header file that can't be
put in the cpp file, which makes it kind of hard. But it's an
interesting concept.
> >It also makes it easier to write interface classes, and they have no
> >.cpp file at all. ;)
>
> Well, I think that should be the exception rather than the rule.
Interfaces are good, and there will be more of them later. MI is ok, as
long as one doesn't have attributes in more than one class.
On the other hand, as long as you write documented code that does nice
things, I'm happy. :)
/Basic
|
|
From: Daniel B. <ba...@we...> - 2000-03-12 11:44:53
|
On Sat, Mar 11, 2000 at 04:08:42PM -0800, Marius Sundbakken wrote: > I did a few trivial changes to Yact. I have to get to know the code. Sounds like a good idea! > I tried to do a rubber band selector, but I got all confused by the > inputhandler/provider system. Oh. Well, it's pretty easy. The YInputHandler hierarchy is a state machine for the YDiagram class. To keep things a little bit separate, YDiagram implements the YInputProvider protocol, which is the only link the YInputHandler has to the world. The YInputHandler classes are singletons, which is why all the methods has a "client" parameter. In your case, what you need to do is to add some code in YIHUnactive, the mousePressed() method. Also, the YDiagram::m_currentView must be changed, as it only supports a single selected view right now. > Also, the indention used must be pretty unique. Why do you do this: > > int > foo; > > in the class headers? What's the rationale? Unfortunately, Emacs gets a > bit confused by such "indenting." The rationale is to keep minimize the number of lines that gets affected by a change. For methods, which can have rather long types (including "virtual" etc), it is also a way to get the method name into a place where it is easily spotted. For attributes it looks rather strange though, so I'm rewriting that. Which of course that Vim is a better and more intelligent editor than Emacs, as it has no problems with that indentation. *grin* > Personally I prefer to have the comments for memeber functions in the cpp > file, not in the header. I mean, I do all the work in the cpp files, not > in the header files, so to me, it makes little sense to have the comments > there. Is there a reason for having the comments in the header files? For me it's a way of keeping apart the difference between the interface and the documentation of _what_ the class does from the implementation and _how_ and _why_ it does it. The header file is the "contract" of the class, and as such, is a good place to put the documentation. It also makes it easier to write interface classes, and they have no .cpp file at all. ;) /Basic P.S. I knew that the "I agree with you" thing you pulled on me earlier was just a trick. :) D.S. |
|
From: Marius S. <ma...@fi...> - 2000-03-12 00:13:23
|
I did a few trivial changes to Yact. I have to get to know the code. I
tried to do a rubber band selector, but I got all confused by the
inputhandler/provider system.
Also, the indention used must be pretty unique. Why do you do this:
int
foo;
in the class headers? What's the rationale? Unfortunately, Emacs gets a
bit confused by such "indenting."
Personally I prefer to have the comments for memeber functions in the cpp
file, not in the header. I mean, I do all the work in the cpp files, not
in the header files, so to me, it makes little sense to have the comments
there. Is there a reason for having the comments in the header files?
- Marius
|
|
From: Daniel B. <ba...@we...> - 2000-03-11 09:57:11
|
On Thu, Mar 09, 2000 at 10:10:38PM -0800, Marius Sundbakken wrote: > Not that you've seen anything I've made, have you? :-) But I'm glad you > trust me :-) I've seen your QtVu web page. :) > Actually, I was thinking about the entity editors, like the class editor. Ok. Well, I have no opinions on this myself, so any ideas are welcome. For starters though I'm still thinking of beginning with that simple one item per line thing, just to get things visible and editable. Most of the work should be done in the individual item editors, reducing the problem to a minor layout thing. > However, I agree with you. If you have a lot of classes, packages etc, the > diagrams drown in all the other stuff. I often find myself browsing the > tree in Rose searching for diagrams. In those situations the tab bar at the top of the diagrams, as Object Domains has it, is a life safer. > >Suggestion: Something like the MS Visual Studio tools, with several > >treeviews on different tab pages, each with a different focus. > > Yes, that is the obvious solution. Good solutions should be obvious. :) > How many "types" of trees do we need? > > - Views / Diagrams > - Packages / Classes > - All-in-one? > > Either way, it is a trivial issue whether to use combobox or tabbar. That's true. The major difference is that with the combobox solution there is room for longer texts. > I guess this is a typical example of a Model-View case, right? Exactly. > Anyway... hm... I never got around to modify Qb so that it would compile, You didn't? I did it myself right now, just to see how hard it would be, and it was trivial: In qb.pro, just remove all files containing the string "odbc" in their names, and in yact.pro remove the entire second line of libraries, the one containing the odbc stuff. Rerun tmake, and that's it. Here is the patch, after copying qb.pro to qb2.pro, and yact.pro to yact2.pro. --- qb/qb.pro Wed Mar 1 19:38:14 2000 +++ qb/qb2.pro Sat Mar 11 10:04:06 2000 @@ -32,10 +32,6 @@ src/qbitemdesc.h \ src/qbitemvisitor.h \ src/qblink.h \ - src/qbodbc.h \ - src/qbodbccolumn.h \ - src/qbodbcsource.h \ - src/qbodbcstatement.h \ src/qboid.h \ src/qbquery.h \ src/qbrelation.h \ @@ -62,9 +58,6 @@ src/qbitemdesc.cpp \ src/qbitemvisitor.cpp \ src/qblink.cpp \ - src/qbodbccolumn.cpp \ - src/qbodbcsource.cpp \ - src/qbodbcstatement.cpp \ src/qboid.cpp \ src/qbquery.cpp \ src/qbrelation.cpp \ --- yact/src/yact.pro Wed Feb 23 21:59:22 2000 +++ yact/src/yact2.pro Sat Mar 11 10:05:21 2000 @@ -14,8 +14,7 @@ DESTDIR = bin MOC_DIR = meta OBJECTS_DIR = obj -unix:LIBS = -L/usr/src/qb -lqb \ - -L/usr/local/unixodbc/lib -lodbc -llog -lini -lodbcinst -llst +unix:LIBS = -L/usr/src/qb -lqb2 win32:LIBS = qb.lib "$(SYBASE)\win32\lib\odbc32.lib" \ imm32.lib /Basic |
|
From: Marius S. <ma...@fi...> - 2000-03-10 06:15:09
|
> > I'm not likely to bother downloading a program that looks like shit > > (even though it may be technically good). > >That's true, and since I've got no sense of aestetics myself, I'm glad >I've got you on the team. :) Not that you've seen anything I've made, have you? :-) But I'm glad you trust me :-) > > When it comes to the GUI design, how should we make the editors? > >Good point, and the jury is still out on that one. The problem with the >treeview thing that Rose (and Object Domain) uses is that it is hard to >get a good overview of just the diagrams in the model, as all types of >entities are intermixed. On the other hand, putting the diagrams on >tabs at the top (as Object Domain does), creates problems when the tab >list becomes full. Actually, I was thinking about the entity editors, like the class editor. However, I agree with you. If you have a lot of classes, packages etc, the diagrams drown in all the other stuff. I often find myself browsing the tree in Rose searching for diagrams. >Suggestion: Something like the MS Visual Studio tools, with several >treeviews on different tab pages, each with a different focus. One >might show the normal UML view, one just shows diagrams, and another one >shows something else. If implemented with visitors (even if I have no >idea HOW, right now), it ought to be rather easy. Yes, that is the obvious solution. It doesn't scale as well as a combobox above the tree, but I think tabs is better GUI design. The scalability does not have to be a real problem, though. How many "types" of trees do we need? - Views / Diagrams - Packages / Classes - All-in-one? Either way, it is a trivial issue whether to use combobox or tabbar. I guess this is a typical example of a Model-View case, right? There's one model repository containing the structure, and then several views of this model. Anyway... hm... I never got around to modify Qb so that it would compile, and thus I could not try Yact either. Since you know the Qb code, it is probably a lot easier for you to make it more compatible (you said ODBC and SQL wasn't necessary, right?), so, do you think you can do that? I'd rather not spend time on getting it to compile... Heck, I almost feel ashamed whenever I take the time write emails like this instead of working :-( - Marius |
|
From: Daniel B. <ba...@we...> - 2000-03-09 21:30:05
|
On Thu, Mar 02, 2000 at 08:18:01PM -0800, Marius Sundbakken wrote: > I'm not likely to bother downloading a program that looks like shit > (even though it may be technically good). That's true, and since I've got no sense of aestetics myself, I'm glad I've got you on the team. :) > When it comes to the GUI design, how should we make the editors? Good point, and the jury is still out on that one. The problem with the treeview thing that Rose (and Object Domain) uses is that it is hard to get a good overview of just the diagrams in the model, as all types of entities are intermixed. On the other hand, putting the diagrams on tabs at the top (as Object Domain does), creates problems when the tab list becomes full. *thinks for a moment* Suggestion: Something like the MS Visual Studio tools, with several treeviews on different tab pages, each with a different focus. One might show the normal UML view, one just shows diagrams, and another one shows something else. If implemented with visitors (even if I have no idea HOW, right now), it ought to be rather easy. /Basic |
|
From: Daniel B. <ba...@we...> - 2000-03-08 21:38:36
|
Now focus tags are drawn on relationship lines as well. (Not to mention that relationships are also drawn at the _correct_ position of the viewport...) /Basic |
|
From: Marius S. <ma...@fi...> - 2000-03-03 04:21:52
|
>I just uploaded two little screen shots (in PNG) of the browser window >and the class editor (if you could call it that), to the Yact main site: >http://yact.sourceforge.net > >I'm SO proud of the link arrows. :) Hehe... they're neat! Btw: Screen shots are important for open source projects. It has a sort of psychological effect. I probably put far too much value in them myself, but esthetics matter to me. I'm not likely to bother downloading a program that looks like shit (even though it may be technically good). When it comes to the GUI design, how should we make the editors? Shall we use tabs as Rational Rose uses? Object Domain also uses tabs, but in a slightly different way. Alternatively, we can use a tree or a list as more and more programs starts to do. See for example the KControlPanel, Eudora preferences, Netscape preferences... It's more scalable than tabs (stacked tabs sucks!), but not as familiar. Anyway, since both cases require each page to be a widget, it's no big hassle to convert between them. - Marius |
|
From: Daniel B. <ba...@we...> - 2000-03-02 22:31:14
|
Hi, I just uploaded two little screen shots (in PNG) of the browser window and the class editor (if you could call it that), to the Yact main site: http://yact.sourceforge.net I'm SO proud of the link arrows. :) /Basic |
|
From: Marius S. <ma...@fi...> - 2000-03-01 22:12:04
|
>One of the last postings on the Qt list solved a little problem for us, >when it comes to storing a diagram. Don't you agree it would work >rather nicely to save the positions and sizes of the widgets as floats >between 0 and 1? With a little scaling button (thank you Qt), it would >make working on different screen resolutions rather easy. I saw that post myself, and I thought exactly the same :-) - Marius |
|
From: Daniel B. <ba...@we...> - 2000-03-01 21:07:32
|
Hi, One of the last postings on the Qt list solved a little problem for us, when it comes to storing a diagram. Don't you agree it would work rather nicely to save the positions and sizes of the widgets as floats between 0 and 1? With a little scaling button (thank you Qt), it would make working on different screen resolutions rather easy. /Basic |
|
From: Marius S. <ma...@fi...> - 2000-02-27 22:37:00
|
> > I did some basic PHP programming for the new QtVu homepage. It's not > > done yet, but you can see it at http://qtvu.sourceforge.net/new/ > >Very nice! Not that I'd have very much time doing much about the web >pages right now, but PHP is definately something I'll try to use soon. Thanks. When I was going to make the new webpages, I looked around on all those meta HTML etc. things. I ended up using PHP. It is widely used, it is open source and seems quite powerful. Besides, SourceForge supports it (SourceForge is written in PHP). >Perhaps you could make the php files available as a separate module? :) What's a module? :-) Seriously, that's how much I know about PHP! - Marius |
|
From: Marius S. <ma...@fi...> - 2000-02-27 22:32:27
|
> > >Whaddya like the inheritance arrow, btw? :) > > Huh? > >Haven't you synced with the latest cvs source? :) Oups :-) I'll try it this evening. > > Btw: Two things about the configuration of the mailinglist: > >Both sound reasonable... But where do I change it? I looked all over >the mailing list admin page, and found absolutely nothing. :( >Perhaps I'm blind today, it wouldn't be the first time. When you created the list you were sent a mail. In it was a link to the settings page for the mailinglist together with the password. The link is probably: http://lists.sourceforge.net/mailman/listinfo/yact-dev - Marius |
|
From: Daniel B. <ba...@we...> - 2000-02-27 20:53:14
|
On Sun, Feb 27, 2000 at 12:28:01PM -0800, Marius Sundbakken wrote: > Qt 2.1 will have a series of new classes for drawing. QCanvas is probably > going to be very, very convenient for us. Ah, I just love Qt :-) Yes, it will definately be worth checking out. My love for Qt didn't exactly become any lesser when I realized that in order to draw the arrow at the end of the inheritance line rotated to the correct angle, I didn't a full _three_ lines to do it. /Basic |
|
From: Daniel B. <ba...@we...> - 2000-02-27 20:48:16
|
On Sun, Feb 27, 2000 at 10:20:58AM -0800, Marius Sundbakken wrote: > >A freshly generated Doxygen doc is now available on the newly moved > >website http://yact.sourceforge.net. > > Great! I took a quick look, and Doxygen procudes some really neat pages > now (it's been a while since I've used it, so I haven't tried the new > versions). A lot of functions are not commented, but still. Thanks. It's not very new though, I use the version from 990425. If you see any functions or classes you really don't understand and would like to have documented a little, just let me know. > Another thing for the web page: Put up the OD files for the diagrams, > and not just the pictures. I would if I could, but I don't have access to OD anymore, and the files are long gone. I'll get Rational Rose soon, so I'll try to put up those files instead. > I did some basic PHP programming for the new QtVu homepage. It's not > done yet, but you can see it at http://qtvu.sourceforge.net/new/ Very nice! Not that I'd have very much time doing much about the web pages right now, but PHP is definately something I'll try to use soon. Perhaps you could make the php files available as a separate module? :) /Basic |
|
From: Daniel B. <ba...@we...> - 2000-02-27 20:48:10
|
On Sun, Feb 27, 2000 at 10:12:09AM -0800, Marius Sundbakken wrote: > >Whaddya like the inheritance arrow, btw? :) > > Huh? Haven't you synced with the latest cvs source? :) > Btw: Two things about the configuration of the mailinglist: Both sound reasonable... But where do I change it? I looked all over the mailing list admin page, and found absolutely nothing. :( Perhaps I'm blind today, it wouldn't be the first time. /Basic |
