there is a new snapshot release available at:
http://github.com/downloads/jri/deepamehta3/deepamehta3-v0.4-20100722.zip
It is easy to install and to uninstall.
Installation instructions:
http://github.com/jri/deepamehta3
To update an existing installation:
1) update all DeepaMehta bundles via OSGi console.
2) quit OSGi runtime
3) delete the folder "deepamehta-db"
4) restart OSGi runtime
This time it is not possible to keep your database.
Improvements for users:
- Double-clickable starter scripts included, no terminal interaction required anymore.
- Detail panel: prettier note layout.
- Type editor: the topic type's data fields can be reordered by drag'n'drop.
- Bug fixes: timestamps displayed properly and are no longer user-editable.
For developers:
- New concept: "Data Field Renderer". For every data field the JavaScript class to be used as renderer can be declared. A data field renderer is responsible for both, data rendering and form generating/processing. The DeepaMehta client provides a number of standard data field renderers. Further data field renderers are supplied by plugins.
- New "editable" attribute for Data fields: data fields can be editable (the default) or read-only.
- Note: the data field's data format has changed. See documentation in the wiki:
http://wiki.github.com/jri/deepamehta3/
Tell me if it is working for you, especially the Linux and Windows starter scripts.
Cheers,
Jörg
Yes I also think it is slower,
I noticed also a big degradation in terms of load on my computer.
While doing some number crunching the dm3 v0.4 gets really
slow, while v0.3 had no big problems with this.
> instead of: This is MY Knowledge environment and I just LOOK
> into what I want which is already there (as contrasted by
> fetching hidden items, which MAY take a little time.)
> Even if the detail text ("description") is a bit quicker, the
> rich obtrusive "under the hood" information displayed, is
> particularly responsible for the delay impression.
Is the rendering already segmented or do we have to wait
for all relations (and their icons?) to be loaded before the
first parts of the detail pane gets rendered ?
To me it is not yet clear if the database is the problem
see for example this thread
http://www.mail-archive.com/us...@lists.neo4j.org/msg04036.html
or if just the rendering is still sub optimal
> Also the requirement to save details text, contradicts the
> immediacy confidence.
>
This could handled via the jquery .blur() event,
but as a side effect this will close the tinymce
whenever you move the mouse outside of the
detail pane.
I personally find the html editor to heavy.
Torsten
>> - Detail panel: prettier note layout.
>> ...
>> Tell me if it is working for you, especially the Linux and Windows starter scripts.
>
> Yes, it works. BUT, it is again slower, and regularly shows a
> wait symbol before opening the wysiwyg detail pae.
Thank you for the feedback!
Your note about performance comes as a surprise to me.
What is the actual case you're talking about?
- Takes displaying the information too long when you click a topic?
- Takes displaying the WYSIWYG editor too long when you click the Edit button?
- What wait symbol to you mean? Turns the mouse pointer into a wait cursor or do you mean the "load spinner" when the WYSIWYG editor loads in the right panel?
- How much content does the topic have (how much characters)?
- How much relations does the topic have?
- What type of topic did you tried? A Note?
- How much topics do you have in your database?
- Did you tried it in different browsers? Are the results the same?
- Do you use the latest snapshot release (deepamehta3-v0.4-20100722.zip)?
- How old is your computer?
My experience is quite different than your's and I would like to know why.
Regardless if I have a topic with 100 content characters and 3 relations or a topic with 35000 content characters and 25 relations, when I click it I see its information immediately, without notable delay.
> I don't understand anything about the architecture, but as an end
> user,
> I think it must be much faster to compete with DM2.
>
> As I wrote on Feb 4th,
>> In DM2, the great competitive advantage was a unique IMMEDIACY
>> of getting verbal details (in the right pane) to the visual
>> overview (in the left pane). This is currently lost: The right
>> pane builds up too slowly
One possible optimization would be to load and display the main content first. Context information (e.g. relationships) could then load in the background. This optimiziation could be realized in a later release.
> Although some extreme delays mentioned then, are now fixed, the
> general impression is still: I click, and the system reacts,
> instead of: This is MY Knowledge environment and I just LOOK
> into what I want which is already there (as contrasted by
> fetching hidden items, which MAY take a little time.)
> Even if the detail text ("description") is a bit quicker, the
> rich obtrusive "under the hood" information displayed, is
> particularly responsible for the delay impression.
I like the notion of "This is MY Knowledge environment and I just LOOK into what is already there". This vivid user-centered position tells us clearly the ultimate goal to achieve.
> Also the requirement to save details text, contradicts the
> immediacy confidence.
Yes, saving should be no explicit operation for the user. All changes could be saved automatically once the user left the topic, like in DM2. The DM2-style could be realised in a later release.
The reason why DM3 has a Save button for the moment is that some applications needs to make "I have finished" an explicit user operation. Consider applications, that must perform e.g. a consistency check on the user input before the user can proceed.
The challenge I see here is the combination of an absolutely passive machine that provides the user a "cognitive home", the think tool you're talking about -- DeepaMehta's ultimate goal -- with a partly active machine that supports defined workflows.
Anyway, I think the Save button will vanish soon :-)
Cheers,
Jörg
> Am 22.07.2010 17:37, schrieb Jörg Richter:
>> - Double-clickable starter scripts included, no terminal interaction required anymore.
> This works for me on ubuntu 10.04
> but I have to choose "run in terminal"
> it is not working if I choose "run"
Thanks for that info!
So, I guess double-clicking doesn't work, right?
Then, on Linux "run in terminal" seems to be the canonical way to start DM right from the file browser.
I will put this info in the README.
Do you use GNOME or KDE? (or something else?)
Makes this a difference in regards of starting a shell script from the file browser?
(sorry for the generic Linux questions.)
>> This time it is not possible to keep your database.
>>
>> - Note: the data field's data format has changed. See documentation in the wiki:
>> http://wiki.github.com/jri/deepamehta3/
> Will there be a future changes to the database?
Yes, there will definitely be changes of the data format in the future.
DeepaMehta copes with that constant flux by both, its migration management, and its release plan.
> For me it would be very important to know when
> the database will be in a final state, to know when to
> switch from testing with nonsense data to real data.
=> Start entering real data once DM3 v0.4 is released.
This release is planed for the end of July.
DeepaMehta Migration Management:
The DeepaMehta core already has a migration facility, for both, the core itself and for the plugins. Once a new version of DeepaMehta or a plugin is installed, the migration facility cares about updating the database if required. For the user this happens automatically.
Technically, the migration facility keeps track of the DeepaMehta core version and all plugin versions, and automatically runs migration code when new installed software is detected.
For the (core or plugin) developer, this service doesn't come for free. She must provide the migration code. Theoretically she must do so for every code commit that relies on a changed data format.
Since there may be several (data format changing) code commits per day, it could become a very time-consuming task for the developer to supply all the required migration code. This is where the release plan comes in.
DeepaMehta Release Plan:
Releases that are meant to be installed by END USERS have a proper version number (without any timestamp in it), e.g. v0.4, v0.4.1, v0.5, v1.0, v1.0.1, v1.1
Every end-user release will be accompanied by migration code that updates the database from the previous end-user release. However, the user is not forced to install all versions. If the user skips a version the migration facility will run all required migrations in sequence.
It is planed to release a new minor release (v0.4, v0.5, ...) about every 3 months. Micro versions (v0.4.1, v0.4.2, ...) will be released as reasonable.
On the other hand DEVELOPER releases ("snapshot" releases) are not guaranteed to be accompanied by migration code. Thus, developers might be required to reset their database when switching to a new snapshot release.
Snapshot releases have a version number with a timestamp in it, e.g. v0.4-20100722.
This example denotes a release on the way to the end user release v0.4, which not yet exists.
So:
=> Put real data in a end user release.
=> Do not put real data in a snapshot release.
=> Do not update a end user release (containing real data) with a snapshot release.
=> If you're both, a user (with real data) and a developer maintain 2 separate DeepaMehta installations.
Cheers,
Jörg
>> Your note about performance comes as a surprise to me.
>
> Well, I wrote on 03.02.2010, at 23:58: "The right pane builds up too
> slowly"
Please understand: technologically the current v0.4 is a completely new thing. It has nothing in common with the v0.3 you talked about half a year ago.
Also the usage scenario is completely different. You used v0.3 as a remote application (while being online). In contrast v0.4 is installed locally (for the moment).
So, "it is too slow" doesn't tell me anything useful.
It would be helpful if you describe in detail what you've done and what you experience, which versions you used, and how the experience of a particular version relates to another version.
=> Do you recognized a performance degradation in v0.4-20100722 in contrast to v0.4-20100710?
=> What means "too slow"? What's the actual delay about? 0.1 sec, 0.5 sec, 2 sec, 10sec?
>> What is the actual case you're talking about?
>> - Takes displaying the information too long when you click a topic?
>
> Yes. Even if the important info (the one of the DM2 right pane) comes
> a little sooner, this info is buried among useless info which keeps loading,
> so you can look at it only after the right pane is loaded.
"buried among useless info" ... What do you mean?
It would be more useful (and more fun to respond to) if you would stop your bashing talk mode and start using a more objective and constructive language.
>> - Did you tried it in different browsers? Are the results the same?
> Are you kidding? Of course I would like to test with my IE, but I have
> to use Ffx, and I have the installed the latest one for that reason.
Dito.
My experience is quite different than your's and still I would like to know why.
Regardless if I have a topic with 100 content characters and 3 relations or a topic with 35000 content characters and 25 relations, when I click it I see its information immediately, without notable delay.
For the moment I have no access to a windows machine.
@x28: perhaps we can alleviate tension when talking about exciting usecases and roadmaps when we meet personally at PKM, while having a cold beer.
Cheers,
Jörg
>> - Did you tried it in different browsers? Are the results the same?
> [...] I would like to test with my IE, but I have to use
> Ffx, and I have the installed the latest one for that reason.
Besides Firefox DM3 v0.4 runs in Safari.
There are reports it runs also in Chrome.
Regarding IE: open its (JavaScript) console (I don't know how) and report the error messages to us developers.
Cheers,
Jörg