Re: [Wonder-disc] RuleModeler 1.2

[<ste...@se...>]

On Aug 21, 2006, at 11:59 AM, Anjo Krank wrote:

>
>>
>> On Aug 21, 2006, at 11:05, Anjo Krank wrote:
>>
>>> It was Target level, thanks!
>>>
>>> This is really nice :) Some nits to pick, though:
>>>
>>> - the model name should be better than "d2w - Resources", which =20
>>> is the name of about every file.
>>
>>
>> You might name it differently, though D2W wouldn't load it =20
>> automatically. Now, for installed files (i.e. files in APP.woa/=20
>> Contents/Resources or FRAMEWORK.framework/Contents/Resources), we =20
>> could display the app/framework name; till now I used the parent =20
>> directory's name, thinking files in project, not the installed one.
>
> In all Wonder-based Projects, the models are in a Folder =20
> "Resources"... I'd just take either both levels or just the first =20
> one that is *not* named Resources.


OK, done. Now ignores filename when d2w.d2wmodel - displays nearest =20
parent folder name different than Contents, Versions, A, Resources.


>>> - if possible, the "Open Recent" should also have better names
>>
>>
>> I didn't look at it; I'll check that. Normally, Cocoa tries to =20
>> give some clues when two files have the same name.
>
> The menu didn't update anymore? Well, it works now, so never mind.


Cocoa will not show 2 entries with the same name; it will display =20
parts of their path allowing to distinguish them. Of course, if you =20
have only one entry, it will display d2w.d2wmodel.


>>> - list view in model group should have color some indication =20
>>> which file a rule belongs to
>>
>>
>> Please give more info about that topic; you want one color per model?
>
> Yes, probably in place of the checkbox. Something like the Finder =20
> colors, maybe. But it's not super important.


Not done. Let's keep it for later; changing background color would do =20=

the trick, or maybe like Mail's labels, with background rounded corners.


>>> - font size in the list should be smaller
>>
>>
>> Easy to do. For both group and model lists?
>
> Yes.


OK, done.


>>> - the model group window should look different in some way (not =20
>>> sure how, I use Unity). Fixed: I just dragged the bottom part all =20=

>>> the way down, doesn't make much sense anyway.
>>
>>
>> Yes. I left the detail view, as it could be useful sometimes, but =20
>> I might hide it at group opening.


Not done. Programatically changing the splitview size is not easy; we =20=

should use RBSplitview, for example.


>>> - kinda weird: when you resize columns, they resize in all =20
>>> windows... not sure if it should do that
>>
>>
>> That's a bug. Setting a different autosave name to the tableview =20
>> in the group nib should fix that.


Actually, it's not a bug, it's a feature! We could disable that, by =20
either not saving any tableview config, or by setting a custom name =20
to each tableview (for example the display name of the model). Not =20
changed for the moment. I suggest adding a pref to keep current =20
behavior or to use one perf per model.


>>> - en/disable creates buggy qualifiers
>>
>>
>> I didn't change that part of the code, I guess (hope...). I'll =20
>> have a look.


Fixed (if we talk about the same bug). There was a recursive call =20
when reverting a model with a rule whose 'enabled' flag had changed. =20
Fixed also bug when closing a model with modifications and model is =20
referenced in an opened group.


>>> - opening files can take ages? Or give the Beachball?
>>
>>
>> Opening groups? Yes, maybe; actually it opens the group and all =20
>> models. Note that edition of a rule in an opened model will be =20
>> immediately reflected in group list. Shark can help to =20
>> diagnosticate that perf problem.
>
> Will try this.


Nothing done for the moment. How many rules have you in your group?


>> I won't work on it for some weeks, I have now other urgent stuff =20
>> to do; I'll just fix the mentioned bugs here.
>
> That'd be great.
>
> I really love this group thing.
>
> Cheers, Anjo


Version number bumped to 1.2.1

Cheers,

St=E9phane