# Any interest in a GUI editor?

**URL:** <https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330>\
**Category:** CSL Development\
**Created:** [October 2, 2007, 9:43pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330 "2007-10-02T21:43:28Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Peter\_Hedlund](https://avatars.discourse-cdn.com/v4/letter/p/ce7236/32.png) [@Peter\_Hedlund](https://discourse.citationstyles.org/u/Peter_Hedlund)\
**Post date:** [October 2, 2007, 9:43pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/1 "2007-10-02T21:43:28Z")

</div>

Hello,

I have a longtime interest in bibliographic software and have tried to think  
of ways to contribute. With the development of CSL and most recently Zotero I  
thought a GUI editor to generate and maintain csl files could be useful.

Is there any interest in such a project? I have started a small project mainly  
as a proof of concept, that I think it should be possible to build on. With  
the advanced features of CSL such as macros, substitute, and conditionals  
it’s not entirely straightforward to make a traditional linear interface for  
citation and bibliography layout.

Have a look at [http://www.scripps.edu/mb/hedlund/csledit.html](http://www.scripps.edu/mb/hedlund/csledit.html) and tell me what  
you think.

Thanks,  
Peter

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [October 2, 2007, 9:58pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/2 "2007-10-02T21:58:21Z")

</div>

Hi Peter,

Peter Hedlund wrote:

> I have a longtime interest in bibliographic software and have tried to think  
> of ways to contribute. With the development of CSL and most recently Zotero I  
> thought a GUI editor to generate and maintain csl files could be useful.
> 
> Is there any interest in such a project?

Yes, absolutely! Johan Kool had worked on a Cocoa version awhile back  
(before recent changes) as well. The more the merrier.

> I have started a small project mainly  
> as a proof of concept, that I think it should be possible to build on. With  
> the advanced features of CSL such as macros, substitute, and conditionals  
> it’s not entirely straightforward to make a traditional linear interface for  
> citation and bibliography layout.

Yes, this indeed may be a challenge.

> Have a look at [http://www.scripps.edu/mb/hedlund/csledit.html](http://www.scripps.edu/mb/hedlund/csledit.html) and tell me what  
> you think.

Looks like a nice start!

The only question I have is about the programming choice. It’s obviously  
totally up to you what you want to do, but it seems to me you might  
consider an option like extending the csledit.xul interface the Zotero  
guys started.

Alternately, I’ve been playing with the new Buzzword Flex/AIR  
application the past couple of days, and am so impressed with the UI I’m  
forgetting the runtime isn’t free 😉

Bruce

---

<div class="post-metadata">

**Author:** ![Peter\_Hedlund](https://avatars.discourse-cdn.com/v4/letter/p/ce7236/32.png) [@Peter\_Hedlund](https://discourse.citationstyles.org/u/Peter_Hedlund)\
**Post date:** [October 2, 2007, 10:26pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/3 "2007-10-02T22:26:54Z")

</div>

> Hi Peter,
> 
> Peter Hedlund wrote:
> 
> > I have a longtime interest in bibliographic software and have tried to  
> > think of ways to contribute. With the development of CSL and most  
> > recently Zotero I thought a GUI editor to generate and maintain csl files  
> > could be useful.
> > 
> > Is there any interest in such a project?
> 
> Yes, absolutely! Johan Kool had worked on a Cocoa version awhile back  
> (before recent changes) as well. The more the merrier.

Yes, I saw that in your repository, but it uses the old schema, right? and I  
don’t know a thing about Mac development.

> > I have started a small project mainly  
> > as a proof of concept, that I think it should be possible to build on.  
> > With the advanced features of CSL such as macros, substitute, and  
> > conditionals it’s not entirely straightforward to make a traditional  
> > linear interface for citation and bibliography layout.
> 
> Yes, this indeed may be a challenge.

I’m glad we agree 🙂

> > Have a look at [http://www.scripps.edu/mb/hedlund/csledit.html](http://www.scripps.edu/mb/hedlund/csledit.html) and tell me  
> > what you think.
> 
> Looks like a nice start!
> 
> The only question I have is about the programming choice. It’s obviously  
> totally up to you what you want to do, but it seems to me you might  
> consider an option like extending the csledit.xul interface the Zotero  
> guys started.

The number one reason is of course that I’m somewhat familiar with Qt. But, to  
me it’s also a logical choice since it should be possible to compile  
applications that run natively on Linux/Unix, Windows, and Mac.

The csledit.xul is only a text edit window where you work directly on the xml,  
or did I miss something?

Besides, isn’t the plan to use csl not only in Zotero?

> Alternately, I’ve been playing with the new Buzzword Flex/AIR  
> application the past couple of days, and am so impressed with the UI I’m  
> forgetting the runtime isn’t free 😉

This is something I’m not at all familiar with. But I’m very unlikely to adopt  
a non-FLOSS approach.

Thanks,  
Peter

---

<div class="post-metadata">

**Author:** ![Dan\_Stillman](https://avatars.discourse-cdn.com/v4/letter/d/ecb155/32.png) [@Dan\_Stillman](https://discourse.citationstyles.org/u/Dan_Stillman)\
**Post date:** [October 2, 2007, 10:49pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/4 "2007-10-02T22:49:03Z")

</div>

> Peter Hedlund wrote:
> 
> > > I have a longtime interest in bibliographic software and have tried to  
> > > think of ways to contribute. With the development of CSL and most  
> > > recently Zotero I thought a GUI editor to generate and maintain csl files  
> > > could be useful.
> > > 
> > > Is there any interest in such a project?
> > 
> > Yes, absolutely! Johan Kool had worked on a Cocoa version awhile back  
> > (before recent changes) as well. The more the merrier.

Ditto from us at Zotero.

> > The only question I have is about the programming choice. It’s obviously  
> > totally up to you what you want to do, but it seems to me you might  
> > consider an option like extending the csledit.xul interface the Zotero  
> > guys started.
> 
> The number one reason is of course that I’m somewhat familiar with Qt. But, to  
> me it’s also a logical choice since it should be possible to compile  
> applications that run natively on Linux/Unix, Windows, and Mac.
> 
> The csledit.xul is only a text edit window where you work directly on the xml,  
> or did I miss something?
> 
> Besides, isn’t the plan to use csl not only in Zotero?

I’d echo what Bruce said here as well. It’d certainly make sense for you  
to code in whatever you were comfortable in, but implementing this as a  
Firefox plugin would carry certain benefits, such as being able to pull  
data from the user’s Zotero library and leverage Zotero’s citation  
processor for as-you-type previewing of selected items. That’s the main  
point of csledit.xul. The idea here isn’t that CSL is Zotero-specific in  
any way, but merely that Zotero already offers a data model, an easy way  
to grab sample references, and a CSL processor. I don’t see any preview  
functionality in your mockups, but I think that would be an important  
part of such a tool.

csledit.xul is a very quick hack that runs within the content window,  
but it could easily be transformed into a windowed UI that looked just  
like your mockups. We were planning to integrate its functionality into  
Scaffold (our mini-IDE for translators), but the CSL editor could easily  
be a separate plugin, and we’d be happy to contribute Zotero integration  
code. The Zotero integration could be purely optional.

As an external app, seamless Zotero integration could really only happen  
via some sort of IPC API, which probably won’t exist in Zotero for some  
time.

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [October 2, 2007, 11:11pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/5 "2007-10-02T23:11:00Z")

</div>

Peter Hedlund wrote:

…

> > The only question I have is about the programming choice. It’s obviously  
> > totally up to you what you want to do, but it seems to me you might  
> > consider an option like extending the csledit.xul interface the Zotero  
> > guys started.
> 
> The number one reason is of course that I’m somewhat familiar with Qt. But, to  
> me it’s also a logical choice since it should be possible to compile  
> applications that run natively on Linux/Unix, Windows, and Mac.

Sure, and that’s fine.

> The csledit.xul is only a text edit window where you work directly on the xml,  
> or did I miss something?
> 
> Besides, isn’t the plan to use csl not only in Zotero?

Yes, definitely. See if Dan offers some compelling reasons why it might  
make sense.

When I first was working on CSL, I had the idea of a central repository  
and web interface. I suppose it doesn’t much matter, so long as in the  
end we enable the distributed repository model I envision. With a client  
side app, one could still do that presumably.

Really the goal is to make it easy for lots of users to (relatively)  
quickly create these styles, and for different projects to be able to  
benefit from that infrastructure. Zotero is simply the one out in front  
on deploying CSL.

> > Alternately, I’ve been playing with the new Buzzword Flex/AIR  
> > application the past couple of days, and am so impressed with the UI I’m  
> > forgetting the runtime isn’t free 😉
> 
> This is something I’m not at all familiar with. But I’m very unlikely to adopt  
> a non-FLOSS approach.

Yes, totally understand.

Bruce

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [October 2, 2007, 11:12pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/6 "2007-10-02T23:12:24Z")

</div>

Oh, and …

Peter Hedlund wrote:

> > Yes, absolutely! Johan Kool had worked on a Cocoa version awhile back  
> > (before recent changes) as well. The more the merrier.
> 
> Yes, I saw that in your repository, but it uses the old schema, right? and I  
> don’t know a thing about Mac development.

Yes, old schema. And I wasn’t suggesting you hack on it; just that  
you’re not alone in trying it 😉

Bruce

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [October 2, 2007, 11:15pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/7 "2007-10-02T23:15:07Z")

</div>

Dan Stillman wrote:

> I don’t see any preview functionality in your mockups, but I think  
> that would be an important part of such a tool.

Yes, previewing, and also validation.

Bruce

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [October 2, 2007, 11:33pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/8 "2007-10-02T23:33:32Z")

</div>

BTW, I just tried to build it on OS X, using the latest pre-compiled Qt  
binaries available at Trolltech.

This is what happens:

$ qmake [csledit.pro](http://csledit.pro)  
$ make  
make: \*\*\* No targets specified and no makefile found. Stop.

I have no experience with Qt.

Bruce

---

<div class="post-metadata">

**Author:** ![Peter\_Hedlund](https://avatars.discourse-cdn.com/v4/letter/p/ce7236/32.png) [@Peter\_Hedlund](https://discourse.citationstyles.org/u/Peter_Hedlund)\
**Post date:** [October 3, 2007, 1:31am UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/9 "2007-10-03T01:31:19Z")

</div>

I don’t really have any Mac experience. The only Mac I have access to still  
runs 10.3.9 and doesn’t have the most recent Xcode tools.

If qmake doesn’t give any error I assume a makefile must be generated. Do you  
see one in the csledit folder?

Are the tips at [http://trolltech.com/developer/notes/platforms/osx](http://trolltech.com/developer/notes/platforms/osx) regarding  
compiler version and Intel hardware of any help?

Thanks,  
Peter

---

<div class="post-metadata">

**Author:** ![Johan\_Kool2](https://avatars.discourse-cdn.com/v4/letter/j/cab0a1/32.png) [@Johan\_Kool2](https://discourse.citationstyles.org/u/Johan_Kool2)\
**Post date:** [October 3, 2007, 9:35pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/10 "2007-10-03T21:35:30Z")

</div>

Hello all,

Sorry, I have been quite dormant about this stuff lately. And I am  
afraid I won’t have much time in the near future for this project  
either.

My code for the CSL editor isn’t very useful, and more of an exercise  
in what a GUI might look like. It is certainly quite hard to catch all  
of CSL’s possibilities in a GUI that also remains usable and doesn’t  
overload the user with a plethora of buttons, popups and textfields.

Qt does work on the Mac. But the interface it provides is far from  
pretty, and for that reason I don’t find it the ideal platform for  
developing native software for the Mac.

I think it would lean currently to suggesting implementing a CSL  
editor through a web interface. That would than be ideal in  
combination with a central repository for CSL styles. Editing CSL  
styles should be a relative rare task for the end user, as he will  
likely first try to find a predefined style for his needs, that I feel  
that the advantages of a web interface outweigh those of native  
software.

There are currently many excellent frameworks available for web  
development. We need to find out which one has the best support for  
XML editing and custom forms (we are likely going to need lots of  
those). Other considerations would be the ease of writing and the ease  
of hosting. Something with Python or Ruby would have my preference,  
but I’ll gladly hear others suggestions.

Cheers,

Johan—  
[http://www.johankool.nl/](http://www.johankool.nl/)

---

<div class="post-metadata">

**Author:** ![Peter\_Hedlund](https://avatars.discourse-cdn.com/v4/letter/p/ce7236/32.png) [@Peter\_Hedlund](https://discourse.citationstyles.org/u/Peter_Hedlund)\
**Post date:** [October 3, 2007, 10:36pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/11 "2007-10-03T22:36:38Z")

</div>

This does not answer your question, but I have nevertheless updated  
[http://www.scripps.edu/mb/hedlund/csledit.html](http://www.scripps.edu/mb/hedlund/csledit.html) to give information for the  
Windows platform. The trick there was to specify a release build instead of a  
debug build. I will continue to investigate Mac, but my access and experience  
is limited.

In what way are Qt apps ugly on the Mac? From looking at screenshots and  
documentation everything seems native to me.

Web applications are good, but they also have limitations. Especially in  
keyboard navigation and editing commands. In e.g. Zotero it’s impossible to  
navigate with the keyboard between all edit fields, dropdowns, pluses and  
minuses. It works because most data is imported, but serious editing is  
cumbersome.

A central repository is of course good. Qt in itself is AFAIK not network  
transparent [1] making a pure Qt app limited in accessing remote files.

[1] In contrast to e.g. KDE where you can open files using almost any protocol  
in any application, or [OpenOffice.org](http://OpenOffice.org) which supports at least ftp and webdav  
in its file dialog.

Thanks,  
Peter

---

<div class="post-metadata">

**Author:** ![Johan\_Kool2](https://avatars.discourse-cdn.com/v4/letter/j/cab0a1/32.png) [@Johan\_Kool2](https://discourse.citationstyles.org/u/Johan_Kool2)\
**Post date:** [October 4, 2007, 1:08pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/12 "2007-10-04T13:08:42Z")

</div>

Here are the instructions to compile on Mac OS X:

Install Apple’s Developer Tools

Download and install:  
qt-mac-opensource-4.3.2.dmg[http://www.trolltech.com/download?target=ftp://ftp.trolltech.com/qt/source/qt-mac-opensource-4.3.2.dmg](http://www.trolltech.com/download?target=ftp://ftp.trolltech.com/qt/source/qt-mac-opensource-4.3.2.dmg)

Extract csledit-0.1.tar.gz[http://www.scripps.edu/mb/hedlund/download/csledit-0.1.tar.gz](http://www.scripps.edu/mb/hedlund/download/csledit-0.1.tar.gz)

$ cd csledit

$ qmake [csledit.pro](http://csledit.pro)

$ open csledit.xcodeproj

Click on ‘Build and Run’ in Xcode.

(I needed to edit the 2 scripts in the target to escape a space in my path.  
This is done by selecting the script under the target and showing the  
inspector for it.)

---

<div class="post-metadata">

**Author:** ![Peter\_Hedlund](https://avatars.discourse-cdn.com/v4/letter/p/ce7236/32.png) [@Peter\_Hedlund](https://discourse.citationstyles.org/u/Peter_Hedlund)\
**Post date:** [October 4, 2007, 4:20pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/13 "2007-10-04T16:20:52Z")

</div>

Thank you for the instructions. I added them to the web page together with an  
alternative approach described in the qmake documentation.

Thanks,  
Peter

---

<div class="post-metadata">

**Author:** ![Dan\_Stillman](https://avatars.discourse-cdn.com/v4/letter/d/ecb155/32.png) [@Dan\_Stillman](https://discourse.citationstyles.org/u/Dan_Stillman)\
**Post date:** [October 5, 2007, 7:44am UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/14 "2007-10-05T07:44:08Z")

</div>

Well, remember, Zotero isn’t a web app–the interface is done with XUL,  
which makes it more closely resemble a desktop app but requires more  
manual implementation of keyboard support for certain actions. Full  
keyboard accessibility is still quite possible, though–the only reason  
Zotero doesn’t have it is because we haven’t finished adding it.

An actual web app would likely have a different interface from a XUL  
app, so they’re not really comparable, but there’s no reason a web app  
couldn’t be perfectly usable via the keyboard, either–you’d get  
accessibility for standard HTML elements via the browser and implement  
anything else via JS. Advantages of a web app include 1) no  
download/installation, 2) ability to accept reference data from apps  
like Zotero via GET/POST (like, say, the W3C validators), 3) ability to  
save edited styles via a simple download link (which, if served with the  
proper MIME type, Zotero or another CSL-powered app could auto-install),  
and 4) possible integration with a browsable repository of styles, so  
you could find a template style, click Edit, make a few changes, and  
download into your CSL-powered app.

The advantage of a Firefox extension over a web app, along with Zotero  
integration, is that it’d let you create a tool that felt more like a  
desktop app, with custom context menus, etc., and you could leverage a  
lot of special functionality in the Mozilla framework (for XML handling,  
file I/O, etc.). But that may not be necessary.

The most important thing may be to figure out how you’d be providing  
previewing of styles, since that may affect other design decisions. If  
you weren’t going to leverage Zotero for that, you’d need a CSL  
processor and some way of inputting data. I guess maybe CiteProc could  
help here, though I don’t know much about it or how up-to-date it is.  
But before relying on CiteProc, you (and we, if we were going to  
recommend that people use this rather than a Zotero-integrated tool that  
we develop) would want to know that CiteProc was going to be kept  
up-to-date with the spec.

Another option would be a web app that did previewing using an  
abstracted version of Zotero’s JS-based CSL processor…

---

<div class="post-metadata">

**Author:** ![Peter\_Hedlund](https://avatars.discourse-cdn.com/v4/letter/p/ce7236/32.png) [@Peter\_Hedlund](https://discourse.citationstyles.org/u/Peter_Hedlund)\
**Post date:** [October 5, 2007, 4:04pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/15 "2007-10-05T16:04:24Z")

</div>

Yes, I realize this but I haven’t really gotten that far yet (partly because  
it’s challenging). We’ll see…

Peter

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [October 10, 2007, 1:46pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/16 "2007-10-10T13:46:37Z")

</div>

Johan Kool wrote:

> $ open csledit.xcodeproj
> 
> Click on ‘Build and Run’ in Xcode.

Ah! That works.

So, yeah, it builds and runs on Mac OS X.

I’ve got a few thoughts, which are in part general design thoughts  
prompted by your work Peter.

- I find the “contributors” panel a little funky.

- the categories list may well get pretty long. Is this the right UI  
choice? Am not sure; just asking.

- perhaps because of the above, there’s a need for three panels for the  
metadata. But I wonder if it’d be possible to have it all on one, more  
compact, panel?

- it might be useful to provide some help for users on the id and link  
values. The id, for example, is required.

- that raises the validation issue; ultimately, an editor ought to  
ensure a valid file.

- I like the way you’ve done the “option” settings.

- macros: I wonder if it would make sense to provide a list of macro  
names? We’ve actually reserved an “author” one.

Anyway, that’s all for now. Looking good.

Do you have any ideas about whether it’s possible to GUIify the rest of  
it? I realize it’s hard.

Bruce

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [October 10, 2007, 1:52pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/17 "2007-10-10T13:52:01Z")

</div>

Dan Stillman wrote:

> I guess maybe CiteProc could help here, though I don’t know much  
> about it or how up-to-date it is. But before relying on CiteProc, you  
> (and we, if we were going to recommend that people use this rather  
> than a Zotero-integrated tool that we develop) would want to know  
> that CiteProc was going to be kept up-to-date with the spec.

I can’t commit to that unfortunately.

> Another option would be a web app that did previewing using an  
> abstracted version of Zotero’s JS-based CSL processor…

Yes. If you look in the SVN, CiteProc is now citeproc-xsl, and there are  
citeproc-py and citeproc-rb placeholders as well. Essentially what  
you’re mentioning here is a kind of citeproc-js. I kind of liked the  
idea of thinking in terms of a standard API for citation processing.

For the creation or editing of styles, one doesn’t really need one’s own  
data from Zotero (or whatever); one just needs say 10 rich examples that  
can show the full expressiveness of a given style. I’d imagine one could  
just load some standardized JSON data for previewing.

Bruce

---

<div class="post-metadata">

**Author:** ![Peter\_Hedlund](https://avatars.discourse-cdn.com/v4/letter/p/ce7236/32.png) [@Peter\_Hedlund](https://discourse.citationstyles.org/u/Peter_Hedlund)\
**Post date:** [October 10, 2007, 3:47pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/18 "2007-10-10T15:47:23Z")

</div>

> Johan Kool wrote:
> 
> > $ open csledit.xcodeproj
> > 
> > Click on ‘Build and Run’ in Xcode.
> 
> Ah! That works.
> 
> So, yeah, it builds and runs on Mac OS X.

See the web page for a second way to build on Mac OS X.

> I’ve got a few thoughts, which are in part general design thoughts  
> prompted by your work Peter.

Thank you. This is exactly the type of feedback I was hoping for. Lots of  
stuff are not done yet, and nothing is carved in stone.

> - I find the “contributors” panel a little funky.

Yes… but are there better alternatives?

A question about the schema. The definition for the info element contains  
info-author\* and info-contributor\*. Further down the element info-translator  
is introduced, but it’s never used in the info element. Is this an omission  
or do I miss something?

> - the categories list may well get pretty long. Is this the right UI  
> choice? Am not sure; just asking.

Should it be split for info-fields and info-classes? How many should it be  
possible to select? What does “You can override” vs. “notAllowed” mean?

> - perhaps because of the above, there’s a need for three panels for the  
> metadata. But I wonder if it’d be possible to have it all on one, more  
> compact, panel?
> 
> - it might be useful to provide some help for users on the id and link  
> values. The id, for example, is required.

Yes, I was thinking of having the labels for required fields in bold. Tooltips  
etc. are very easy to add to the ui file using Qt Designer if someone wants  
to help.

> - that raises the validation issue; ultimately, an editor ought to  
> ensure a valid file.

I will most likely introduce a validation menu command. I think validation on  
each save would be too intrusive.

> - I like the way you’ve done the “option” settings.

OK, good.

> - macros: I wonder if it would make sense to provide a list of macro  
> names? We’ve actually reserved an “author” one.

Ah, I thought these were completely user-defined. Where does it say  
that “author” is reserved? Because of cs-names?

> Anyway, that’s all for now. Looking good.

Thanks.

> Do you have any ideas about whether it’s possible to GUIify the rest of  
> it? I realize it’s hard.

Sorting should be pretty straightforward, but after that it gets more  
tricky…

Peter

---

<div class="post-metadata">

**Author:** ![Simon\_Kornblith](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Simon\_Kornblith](https://discourse.citationstyles.org/u/Simon_Kornblith)\
**Post date:** [October 10, 2007, 5:02pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/19 "2007-10-10T17:02:47Z")

</div>

In the latest version of the schema, it’s not. In older versions, it  
was, but when we changed the way sorting works, we got rid of it.

Simon

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [October 10, 2007, 5:59pm UTC](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330/20 "2007-10-10T17:59:12Z")

</div>

Peter Hedlund wrote:

…

> > - I find the “contributors” panel a little funky.
> 
> Yes… but are there better alternatives?

What about something like:

author: _**[name]**_ **[email]** +

> A question about the schema. The definition for the info element contains  
> info-author\* and info-contributor\*. Further down the element info-translator  
> is introduced, but it’s never used in the info element. Is this an omission  
> or do I miss something?

Hmm … not sure. I don’t recall adding that.

One thing to keep in mind is the content model for the metadata is  
borrowed from Atom.

> > - the categories list may well get pretty long. Is this the right UI  
> > choice? Am not sure; just asking.
> 
> Should it be split for info-fields and info-classes? How many should it be  
> possible to select? What does “You can override” vs. “notAllowed” mean?

Well, let’s keep in mind the idea behind this. It goes back to the Atom  
basis.

The idea is that ultimately we will have distributed CSL repositories.  
So Zotero might have some, we might host some here, and if we’re really  
successful there may evolve to be hundreds of them.

The categories here will allow people to find styles in and subscribe to  
only those styles in their area.

I’d expect typically a style will have one (and only one) class, and  
between one and three or so field categories.

> > - perhaps because of the above, there’s a need for three panels for the  
> > metadata. But I wonder if it’d be possible to have it all on one, more  
> > compact, panel?
> > 
> > - it might be useful to provide some help for users on the id and link  
> > values. The id, for example, is required.
> 
> Yes, I was thinking of having the labels for required fields in bold. Tooltips  
> etc. are very easy to add to the ui file using Qt Designer if someone wants  
> to help.

With respect to “help” I was wondering if it could automatically  
generate an id URI? So say when they start a new style the app does  
this, and the field is not editable. To edit it (say they want to add  
their own URI) they have to click some button.

In that (auto) case, the URI could just be a GUUID URN.

> > - that raises the validation issue; ultimately, an editor ought to  
> > ensure a valid file.
> 
> I will most likely introduce a validation menu command. I think validation on  
> each save would be too intrusive.

The only way you’d want to do continuous validation is if you did it the  
way an XML editor does it: flagging the errors with red inline. Probably  
too much work.

Bruce

[Next page](https://discourse.citationstyles.org/t/any-interest-in-a-gui-editor/330.md?page=2)