Bug 263496 - add support for GUID
Summary: add support for GUID
Status: CONFIRMED
Alias: None
Product: okteta
Classification: Unclassified
Component: Structures Tool (show other bugs)
Version: unspecified
Platform: Ubuntu Packages Linux
: NOR wishlist (vote)
Target Milestone: ---
Assignee: Alex Richardson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-18 00:59 UTC by Brad Hards
Modified: 2013-03-12 23:40 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brad Hards 2011-01-18 00:59:32 UTC
Version:           unspecified (using KDE 4.5.1) 
OS:                Linux

[This relates to my work on an Okteta Structure Definition for Compound File
Binary File Format, which is described in MS-CFB specification]

A GUID structure is particularly ugly, because the definition is partly in big-endian terms (see http://en.wikipedia.org/wiki/Globally_unique_identifier), and its best viewed with - separators. 

At the moment, the only thing I can come up with is showing it as an array of 16 uint8 values.

It would be nice to handle GUID, but perhaps this is too specific, and a more general solution that allows the user to define a "custom primitive" or type might be useful.

Reproducible: Always
Comment 1 Alex Richardson 2011-01-18 19:07:33 UTC
I'm not sure how to handle this, UUIDs/GUIDs are used quite commonly so it might be a good idea to implement as a custom type. 

What is however planned for the next version is to be able to define the endianess of an element: BIG, LITTLE and INHERIT from parent. This would only need 2 bits and therefore would not increase memory usage but definitely has use-cases.

This would solve the problem with the last few bytes always being big-endian, but would not give the {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} representation.

Probably custom primitive types are a good idea, this would allow things like UNIX time or other things without having to code them in C++ (and wait for the next version).
It could probably be solved by having a struct/primitive with a special toString() function. Easier in JavaScript, but could also be possible for the XML definitions.
Comment 2 Alex Richardson 2011-02-03 22:56:29 UTC
SVN commit 1218708 by arichardson:

Allow setting the byte order of each element in the XML structure definitions.

An extra attribute is added to all elements named "byteOrder".
The following values are accepted: "inherit" (use value from parent, or if there is no parent the default setting), "fromSettings" (use the value from the settings), "littleEndian", "bigEndian". The value is compared case-insensitively, so even "BiGENDian" will be accepted.

If no value is set it defaults to "inherit".

CCBUG: 263496

 M  +14 -4     abstractstructureparser.cpp  
 M  +3 -0      abstractstructureparser.h  
 M  +18 -15    osdparser.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1218708
Comment 3 Alex Richardson 2011-02-03 23:11:53 UTC
SVN commit 1218713 by arichardson:

Also allow setting the byte order for structures defined in JavaScript. All that has to be done is set the property "byteOrder" of the chosen element to "inherit", "fromSettings", "littleEndian" or "bigEndian" (case insensitive, any invalid values will be "inherit").

I did not add it to the constructor since remembering the order of parameters is not very nice. The following has to be done to set the byte order:

Suppose this is our init() function:

funtion init() {
  var obj = struct({aFloat : float(),
      charArray : array(int32(),4),
      unsignedInt : uint32(),
      bitField : bitfield("unsigned",10)});
  obj.unsignedInt.byteOrder = "littleEndian";
  return obj;
}

This makes unsignedInt use little endian regardless of the byte order from the settings, all others use the byte order from the settings.

CCBUG: 263496

 M  +1 -1      parsers/abstractstructureparser.cpp  
 M  +1 -2      parsers/abstractstructureparser.h  
 M  +5 -1      script/scriptvalueconverter.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1218713
Comment 4 Friedrich W. H. Kossebau 2011-02-03 23:29:32 UTC
Hi,

(In reply to comment #1)
> Probably custom primitive types are a good idea, this would allow things like
> UNIX time or other things without having to code them in C++ (and wait for the
> next version).
> It could probably be solved by having a struct/primitive with a special
> toString() function. Easier in JavaScript, but could also be possible for the
> XML definitions.

Just, toString() would only help with the representation (as string), but not with editing, which would be nice to have as well. E.g. for a time struct you want to edit using a KDatePicker or similar. Same with GUUID where you perhaps even want to create a completely new value, so the editor component has to know the logic to do so.

Perhaps there could be some joint development with the debugger people of KDevelop/KDbg, as they have a same problem when showing/editing memory in debug sessions, I guess.

Renderer/Editors plugins could be installed with identifiers (+priority for rivaling plugins) which would be also used in the old osd as type. If not present the definition simply cannot be used, bad luck (user should be told what is needed). No idea how to connect this to the JavaScript version, perhaps Alex has an idea.
My 2 cents :)
Comment 5 Alex Richardson 2011-02-04 00:16:08 UTC
My idea was the following:

Add a toString() method to the type (in JavaScript)

Add a type property e.g. in your case "GUID"

Additionally add an optional setValueFromString() (or some similar name) method which takes a String i.e. {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}, splits it up and sets the corresponding fields.

Also optionally add a property showChildren, so that e.g. a GUID would appear in the type column, {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} in the value column and no children are shown.


The biggest problem is IMHO reusing already written special types (e.g. Date which would be quite common and painful to implement yourself)
Of course if showChildren is false they can't be edited directly and therefore a setValueFromString() method is needed, if it is not provided showChildren is automatically set to true.

Not sure whether it is feasible looking into KDevelop, since AFAIK they just get a string from GDB and have to parse that.
Comment 6 Alex Richardson 2013-03-12 23:40:18 UTC
Git commit 75df4af37e02d94e83758397f965eba2efc3e8cf by Alex Richardson.
Committed on 13/03/2013 at 00:32.
Pushed by arichardson into branch 'master'.

structures: allow custom string representations of values + unit test

Also install a script that allows creating UUID/GUID structures with
such a custom to string function. It can be used by writing this:

var x = importScript('uuid.js')
var myUUID = x.UUID()
var myGUID = x.GUID()
Related: bug 263491

M  +3    -1    kasten/controllers/CMakeLists.txt
A  +100  -0    kasten/controllers/test/customtostringtest.cpp     [License: LGPL (v2.1+)]
A  +36   -0    kasten/controllers/test/resources/okteta/structures/uuid.js
M  +13   -0    kasten/controllers/test/testutils.h
M  +1    -1    kasten/controllers/view/structures/datatypes/additionaldata.h
M  +12   -1    kasten/controllers/view/structures/datatypes/datainformation.cpp
M  +17   -3    kasten/controllers/view/structures/datatypes/datainformation.h
M  +10   -0    kasten/controllers/view/structures/parsers/datainformationfactory.cpp
M  +2    -1    kasten/controllers/view/structures/parsers/datainformationfactory.h
M  +1    -0    kasten/controllers/view/structures/parsers/osdparser.cpp
M  +1    -0    kasten/controllers/view/structures/parsers/parserutils.h
M  +1    -0    kasten/controllers/view/structures/parsers/scriptvalueconverter_p.cpp
M  +13   -8    kasten/controllers/view/structures/script/classes/defaultscriptclass.cpp
M  +1    -0    kasten/controllers/view/structures/script/classes/defaultscriptclass.h
M  +14   -0    kasten/controllers/view/structures/script/scripthandler.cpp
M  +1    -0    kasten/controllers/view/structures/script/scripthandler.h
M  +2    -1    kasten/controllers/view/structures/script/scripthandlerinfo.h

http://commits.kde.org/okteta/75df4af37e02d94e83758397f965eba2efc3e8cf