Either *one* class for all buttons/fields where the "style" property determines the type; or a class for each type of button/field. These are the alternatives, correct?
Correct.
IOW the first of the two alternatives above is what HC does but maybe *not* what we should do. Why should the user have to cope with [tons of] properties that aren't relevant given the currently selected 'style'.
Agreed.
In the same vein, and if we implement menus as buttons like MC does, then I'd like us to derive a new "menu" class from the "button" class, removing all the button stuff that is not relevant to a menu, and adding all of the menu stuff that isn't relevant to btns. This removal of menu stuff also *simplifies* the button's definition. IOW, a new 'menu' class and a simplified 'button' class.
The MenuItem class in Java does extend the AbstractButton class so this obviously makes a lot of sense. I hadn't actually gotten to thinking about menus in this context yet.
In the same vein, I would also like us to create a new 'label' class which is derived from the 'field' class. This 'label' class is therefore a field which contains text which is displayed on all of the cards which share the current bkgnd (sharedText = true). It does not need many of the properties of a full-fledged field: simple. And it simplifies the 'field' class a little by ridding us of the need to set the sharedText. The sharedText is always false for fields that are not labels.
I'm not sure about this one. It would be useful to be able to have an editable field that appears on all cards of a background (not often, but in some cases). We definitely should have a label class that means uneditable field though since that can give some very useful benefits for blind users (screen reader software will be more likely to realize that it is talking about another object instead of being somewhere the user should type). I would keep the sharedText property for both labels and regular fields though (you would also need to set regular fields as uneditable because they may be disabled currently etc).
they would be different things rather than just changing depending on the type attribute.
The only complication, as you point out below, is that it complicates matters when it comes to *referring* to these different parts as "buttons" or "fields". We might want to consider, though, extending our xTalk to include these new classes. Here are some examples:
set the content of label 1 to "Name:" set the menuItems of menu "File" to myFileMenuItems
The reality is that in FreeCard the type of item is largely irrelevant. For instance:
set the content of <????> 1 to "Name:"
is perfectly unambiguous because there can only be one item of any type either with ID 1, in Z-Axis position 1 (ie: card number). In short, there's no difference between:
set the content of label 1 to "Name:" and set the content of item 1 to "Name:"
both roughly evaluate to the Java code:
card.getItem(1).setProperty(new FCValue("content"), new FCValue("Name:"));
In terms of code, we'd have a base class "Button" which provides a bunch of useful code for anyone implementing new button types...
The button class is derived, in turn, from the 'Part' class which contains the properties that all parts have in common. The geometric properties, for instance, like loc, rect, width, heigth, etc.
Have you been reading the source code? :) This is exactly how things are structured, except I called Part, "Item" which admitedly was a rather poor choice and will likely be changed.
but it wouldn't be seen by the end user normally.
Of course. We don't want to intimidate newbie FreeCard users with such advanced but "arcane" capabilities. I think that 'UserLevels' may once again become relevant for us to implement.
It could just come down to user preference, we may have competing GUIs for FreeCard that do this different ways. One might just have a button tool, field tool and browse tool like HyperCard, another might have popupButton tool, pushButton tool etc like MetaCard does.
A slightly bigger problem is the HyperCard syntax: "get card button 1"
get popup button 1 get push button 1 etc
This would be more keyword to learn but that's not too big a big deal, is it? It may not be an elegant solution though. More reflexion needed.
I think we just design the compiler to ignore whatever you put there then you can call it what you like. If people want checks, the compiler could find the actual button being referred to and ask if it can be referred to by the specified name. There's no ambiguity because you can't have a button 1 and a field 1 on the same card since things are only given a part number.
* Utilize and support inheritance, so the FreeCard engine would pay attention to the Java object inheritance structure of the item implementation. This way, anything that extends the Button class is applicable to the reference "button".
This is how I thought it worked. Are there any serious drawbacks to this? Ex: does it slow things down?
No, this has no impact on performance.
* Allow multiple item types to be recognized by the same HyperTalk type identifier, so all the different
button types would report that they match the type identifier "button" (and "btn") and FreeCard would just respect that.
This identifcation would be based on what? By "paying attention to the Java object inheritance structure of the item implementation" perhaps? By tagging them as they are instantiated? (the 'constructor' handles it)
By asking them.
boolean item.matchesDescriptor("btn");
Item implementations could then decide for themselves what a good descriptor is, or we could just ignore the descriptor altogether.
We'll probably need to support this anyway just to avoid problems with type names clashing when there are a whole range of different third party items available.
I dig your optimism, Adrian, but I don't think this will be an issue for a long long time to come. Let's not take on problems that aren't problems yet. A bit of hindsight is good, of course, but *too much* can be paralyzing! :)
Well, you either plan for this in the design stages (ie now) or it will never be possible because the architecture just won't support it.
Personally, I think the second option is the way to go. Anyway, let me know if you see any issues with this approach.
This may sound 'naive' but it seems to me that BOTH are not mutually exclusive. We'll need to discuss this some more. This is becoming very very interesting. :))
To a degree they aren't mutually expensive, however you'd probably implement it by just overriding the method and passing it on to the super class if desired. That way the part can choose whether or not it can be referred to by the same name as it's super classes.
Alain
Regards,
Adrian Sutton. ---------------------------------------------- Intencha "tomorrow's technology today" Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Freecard-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freecard-general
