qbf-dev Mailing List for Qb application framework
Status: Alpha
Brought to you by:
basic
Menu
▾
▴
qbf-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(7) |
Mar
(3) |
Apr
|
May
(3) |
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-14 06:43:54
|
On Sat, May 13, 2000 at 05:58:57PM -0700, Marius Sundbakken wrote: > >We started to use the XML parser expat at work, so in order to learn it > >I added a little loadXml() method on QbDataSource. It reads entities > [..] > > Cool. Hm... I'd like to see some diagrams on the design. I guess > it's not too hard to understand the code, but... :-) Well, it's not much of a design. :) Expat works by calling C callback functions and providing a "user data" field, so I translate that to methods on a QbXmlReader class. Currently there are three methods on it: startElement() that is called when a new tag is seen, endElement() that is called at the end tag, and fixRelations() that goes through a list of entities with "id" attributes and references to relations. 164 lines of code, all in all. However, XML seems to have a special "ID" type, which I might ought to check for instead, as well as "IDREF" and whatnot. /Basic |
|
From: Marius S. <ma...@fi...> - 2000-05-14 00:59:52
|
>We started to use the XML parser expat at work, so in order to learn it >I added a little loadXml() method on QbDataSource. It reads entities >and resolves relationships by using the special "id" attribute and >having the name of the relationship as an attribute at the source end. >It seems to work fine now, so next it's time to get it to read the class >descriptions as well. And perhaps write some XML files as well. :) Cool. Hm... I'd like to see some diagrams on the design. I guess it's not too hard to understand the code, but... :-) If you should ever make some diagrams, let me know. - Marius |
|
From: Daniel B. <ba...@we...> - 2000-05-13 23:47:55
|
Hi all, We started to use the XML parser expat at work, so in order to learn it I added a little loadXml() method on QbDataSource. It reads entities and resolves relationships by using the special "id" attribute and having the name of the relationship as an attribute at the source end. It seems to work fine now, so next it's time to get it to read the class descriptions as well. And perhaps write some XML files as well. :) /Basic |
|
From: Marius S. <ma...@fi...> - 2000-03-12 16:31:54
|
> > 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.
OK. I'll have one more go at it.
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) :-)
> > int
> > foo;
>
>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*
A pragmatic editor, such as Emacs, will of course do the "columnization"
for you. >:->
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
{
}
:-))
Btw: What tab size do you use?
> > 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.
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. Also, I feel that it is much easier to "forget" the documentation
when it's in the header file and thus become obsolete. 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. 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).
>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.
>P.S.
>I knew that the "I agree with you" thing you pulled on me earlier was
>just a trick. :)
But of course :-)
- Marius
|
|
From: Daniel B. <ba...@we...> - 2000-03-12 11:44:53
|
On Sat, Mar 11, 2000 at 06:58:09PM -0800, Marius Sundbakken wrote: > The CVS repository contains both qbf and qb, but only qb is > maintained, right? From here it looks like it's qbf, actually. Does the timestamps say something else (I've got no web access right now)? /Basic |
|
From: Marius S. <ma...@fi...> - 2000-03-12 03:02:48
|
The CVS repository contains both qbf and qb, but only qb is maintained, right? - Marius |
|
From: Daniel B. <dan...@ti...> - 2000-02-28 08:48:17
|
> I tried compiling Qb, but it needs various database stuff I don't > have. What, exactly, does it require? And, where can I get that? Oh, I forgot about that. The ODBC backend uses unixODBC from www.unixodbc.org and MySQL from www.mysql.org. They should be easy to disable though, if you don't want them, but I haven't gotten around to that yet. The file unixODBCsetup.txt (copied from somewhere) describes how to set it up. At least good enough for me to do it. :) /Basic |
|
From: Marius S. <ma...@fi...> - 2000-02-28 08:07:36
|
I tried compiling Qb, but it needs various database stuff I don't have. What, exactly, does it require? And, where can I get that? - Marius |
|
From: Daniel B. <dan...@ti...> - 2000-02-25 16:12:07
|
> I know very little about XP, but I've noticed that it's > controversial! I don't think it's more controversial than open source. Which of course doesn't say much. But seriously, I've now talked to a few colleagues about it, and even the 55 year olds seems to like most of the ideas. Pretty cool. > I agree with everything you write above though. There's a first for everything... :) > Absolutely. Personally, I mostly use class diagrams, for > example, and I can pretty much live with only that part of UML. Action diagrams or what they're called, when you can see in what order different objects call each other (and themselves) are also quite useful, to find out which method calls are unnecessary. > >I'm not just suffering from the "when your latest tool is a > hammer, all > >problems look like nails" syndrome, am I? > > Maybe :-) *Again*? :) /Basic |
|
From: Marius S. <ma...@fi...> - 2000-02-25 04:44:30
|
>I just read the book Extreme Programming by Kent Beck (I just love him), >and it struck me how close that is to open source development. >Everything is tested all the time since so many people are using it, all >development is used in very short iterations since nobody has very much >time to work on it anyway, integrations are done often since everybody >works against the same cvs server, redesigning and rewriting often since >we don't like to look at bad code, and most importantly, everything is >developed in order of importance (at least to somebody) since everybody >just implements the things that means most to him or her. I know very little about XP, but I've noticed that it's controversial! I agree with everything you write above though. >I hope we can use something as close to this as possible for the Yact/Qb >pair, just implementing the features we want the most, letting the need >from Yact pull the development of Qb. Absolutely. Personally, I mostly use class diagrams, for example, and I can pretty much live with only that part of UML. >I'm not just suffering from the "when your latest tool is a hammer, all >problems look like nails" syndrome, am I? Maybe :-) - Marius |
|
From: Daniel B. <ba...@we...> - 2000-02-24 22:16:50
|
Hi all, I just read the book Extreme Programming by Kent Beck (I just love him), and it struck me how close that is to open source development. Everything is tested all the time since so many people are using it, all development is used in very short iterations since nobody has very much time to work on it anyway, integrations are done often since everybody works against the same cvs server, redesigning and rewriting often since we don't like to look at bad code, and most importantly, everything is developed in order of importance (at least to somebody) since everybody just implements the things that means most to him or her. I hope we can use something as close to this as possible for the Yact/Qb pair, just implementing the features we want the most, letting the need from Yact pull the development of Qb. I'm not just suffering from the "when your latest tool is a hammer, all problems look like nails" syndrome, am I? /Basic |
|
From: Marius S. <ma...@fi...> - 2000-02-24 00:08:23
|
test - Marius |
|
From: Daniel B. <ba...@we...> - 2000-02-08 21:53:09
|
Welcome to the Qb development list! There are not a whole lotta plans ready yet though. :) /Basic |