From: stephan b. <st...@ei...> - 2002-01-25 09:20:19
|
On Thursday 24 January 2002 23:07 pm, you wrote: > > i don't understand - how can copying get any easier than ctrl-drag or > > click/copy? > > Simple: ctrl-drag > simpler: drag > simplest: click. copy by ONLY clicking isn't possible, except in the case that the click generates a copy at a pre-designated point, in which case you must also go through the action of designating that point. > A drag from a piece set should produce an instance of that piece though, > not pull the piece out of the set. Or maybe that IS the behavior? Both behaviours are supported. Objects have a toggle called "drag in copy mode." If this is on, dragging creates a copy, similar to grabbing a piece from the V_MAP interface. If it's off, then the object is moved. Different objects have different default bevahiours here (most will drag/move by default). Any object can be toggled between the two, programmatically or using the Edit dialog of the object. An example of this is when i the conversion of V_MAP files to QUB-native XML. Each "piece" from the V_MAP file is added to a "tray", and the tray itself sets all pieces that are placed in it into drag/copy mode. Then the tray can be used as an unlimited source of pieces. "Default" trays do not do this, and thus have a "limited" number of pieces in them. > > There is a V_MAP clone for Linux which uses the Gtk toolkit. i can't find > > the > > I'll look into it. It's not public, i think - the author sent me the link and i've lost the link. i have the sources, though, and they run just fine on my machine. i can send them to you if you like. > > If you'll write up a specification for such a file format i will write > > you a perl script to convert that into something QUB can use. i've done > > this for V_MAP files - a converted that createx XML out of them. > > We do have a tool which leaves out ALL toolbars, menus, dice, etc: > > > > gcomlauncher mygame.gcom > > > > When used this way, there is no way to add new pieces, etc - i becomes a > > standalone game. (okay, you CAN, but you have to use copy/paste from > > another instance). > > Neat! If you'll come up with a simple script, that's no problem to write up a quick XML generator. Actually, the V_MAP ---> QUB converter doesn't write a single line of XML. Instead it uses a command-line tool which generates QUB objects, and then lets them generate the XML themselves. This means maximum compatibility with QUB - no customized XML writing. So, for example, you might have a simple script which says: board=myboard.gif piece=one.gif piece=two.gif a simple program might convert that to something like this, which would output xml data: gmaker -class GComBasicPiece -pixmaps one.gif -name one gmaker -class GComBasicPiece -pixmaps two.gif -name two gmaker -class GComBasicBoard -child one.gcom,two.gcom -o myboard.board Those three lines (or something like them) would produce xml data for your board, which you could then open with this: gcomlauncher myboard.board (no toolbars, no menus, no dice, etc.) > I meant the handle for collapsing/expanding/moving toolbars, not > tabbed interfaces. The toolbar move thing is deprected in the microsoft > world, where they were invented. That's a part of the UI toolkit, which i can't disable. i don't care much for collapsable toolbars or menus, either. > Meanwhile, developers are happy to create horrific user interaces. > All applications in win32 put the min/max right next to close with no > intevening space. That always was a poor design decision. Under X i always make sure to put them on opposite sides of the windows ;). > Fitt's law demonstrates this is a bad choice, but > yet it remains "popular". What's Fitt's Law? > > XML is one of the reasons that QUB can do 90% of the things it can do. If > > Rusty hadn't added XML support i'd still be hacking away on file parser > > and fretting over ways to embed components. XML solved all these problems > > and more. > > worst: Self-generated parser > good: existing parser and system > better: existing parser and system which works for a variety of data: eg. > XML best: existing parser and system which works for a variety of data, is > easy to edit, is both expressive and terse: eg. libproplist We currently use Qt's XML parser, but that's primarily because QUB is 100% tied to Qt *anyway*. We used libXML for a while, but Rusty didn't like it (he did all the low-level XML stuff). > Really, lisp S-expressions would do everything XML does, and probably > with less editorial effort, easier parsing, and more introspection. > But XML is certainly popular. :-) i don't know lisp (i know of it, of course), but i'm tempted to try my hand at it one of these days. That's an interesting idea, actually - storing program data as program code. The idea that i haven't seen in done in any popular software seems to suggest that there's a reason it hasn't been done. Then again, maybe simply nobody's thought of it yet. ----- stephan Generic Universal Computer Guy st...@ei... - http://www.einsurance.de Office: +49 (89) 552 92 862 Handy: +49 (179) 211 97 67 This email is encrypted with ROT26 encoding. Decoding it is in violation of the Digital Millenium Copyright Act. |