From ian.w.white at gmail.com  Fri Sep 14 14:09:49 2007
From: ian.w.white at gmail.com (Ian White)
Date: Fri, 14 Sep 2007 15:09:49 +0100
Subject: [TxMt Plugins] [ANN] matewatch - free time tracking for textmate
	projects
Message-ID: <f66db9cb0709140709k70e5f1day13093a0f96ab4a64@mail.gmail.com>

Hi list,

I got sick of the bloated time tracking solutions available for OS X,
I work mainly in Textmate, so I rolled my own.

http://blog.ardes.com/articles/2007/09/14/textmate-user-time-tracking-for-free-matewatch

And it's free!

Cheers,
Ian White

-- 
Argument from Design--We build web applications
Western House 239 Western Road Sheffield S10 1LE UK
Mobile: +44 (0)797 4678409 | Office: +44 (0)114 2667712
<http://www.ardes.com/> | <http://blog.ardes.com/>


From bibiko at eva.mpg.de  Thu Sep 20 14:43:25 2007
From: bibiko at eva.mpg.de (Hans-Joerg Bibiko)
Date: Thu, 20 Sep 2007 16:43:25 +0200
Subject: [TxMt Plugins] sendAction Question
Message-ID: <72657E77-A2F4-434A-8942-D582AB5DBF50@eva.mpg.de>

Hi,

I just found this thread in the net. I don't know whether it is too  
late ;)

Regarding to make a selection in a TM document.

Did you try this way:

-(void)setSelectionTo:(NSDictionary*)someOptions
{
	NSString* line;
	NSString* column;
	if(![someOptions objectForKey:@"toLine"])
		line = [[[NSApp targetForAction:@selector(allEnvironmentVariables)]  
allEnvironmentVariables] objectForKey:@"TM_LINE_NUMBER"];
	else
		line = [someOptions objectForKey:@"toLine"];
	if(![someOptions objectForKey:@"toColumn"])
		column = @"1";
	else
		if([[someOptions objectForKey:@"toColumn"] isEqualToString:@"end"])
			column = [NSString stringWithFormat:@"%d",([[[[NSApp  
targetForAction:@selector(allEnvironmentVariables)]  
allEnvironmentVariables] objectForKey:@"TM_CURRENT_LINE"] length] + 1)];
	else
		column = [someOptions objectForKey:@"toColumn"];
	if([someOptions objectForKey:@"length"])
		column = [NSString stringWithFormat:@"%d",[[[[NSApp  
targetForAction:@selector(allEnvironmentVariables)]  
allEnvironmentVariables] objectForKey:@"TM_COLUMN_NUMBER"] intValue] +
			[[someOptions objectForKey:@"length"] intValue]];
	id d = [NSApp targetForAction:@selector(document)];
	[d selectToLine:line andColumn:column];
}

For me it works perfectly ;)

Regards,

Hans



From throw-away-1 at macromates.com  Thu Sep 20 14:45:52 2007
From: throw-away-1 at macromates.com (Allan Odgaard)
Date: Thu, 20 Sep 2007 16:45:52 +0200
Subject: [TxMt Plugins] Dialog API improvements
Message-ID: <9287B3B3-C9EE-4C2C-92A9-421EABADC7F2@macromates.com>

There have recently been a few patches to the Dialog plug-in that I  
have yet to role in.

Mainly because the current architecture does not scale well with new  
functionality.

We have spoken a bit about it on IRC, but since not all contributors  
are on IRC, I am moving the discussion to this list.

The restructuring I am envisioning is to move to a command based  
system so that the basic syntax is:

     tm_dialog ?command? [?options?]

Additionally there will be:

     tm_dialog help ?command?

And just tm_dialog to get a list of commands.

Each command will be responsible for a certain function. Presently we  
have these things (including pending patches):

     Synchronous nib loading
     Asynchronous nib loading
     Pop-up menu
     Type-to-narrow pop-up list
     File dialog (open/save)
     System dialog (color/font)
     HTML tool tips

In my mind, each should be a fully self-contained file providing that  
functionality. From an architectural POV I imagine that tm_dialog will  
basically connect to the Dialog plug-in using distributed-objects (as  
now) and send it:

     1. The full command line (i.e. with arguments)
     2. File handles for tm_dialog?s stdin, stdout, and stderr

Basically all work will then be done in the Dialog plug-in. Which will  
conceptually do:

     1. Check what command the command line arguments contain
     2. Lookup a class/object to handle that command in a dictionary
     3. Pass on the info to that class/object (if found).

So the main thing that needs to be worked out is a super class for the  
commands to subclass. This has two jobs:

     1. Provide a method for the subclass to register a command  
(called e.g. in +load)
     2. Provide an interface for the method that is called when the  
command should go into action

All in all that should be quite simple. Though we probably want a bit  
of sugar, such as converting the arguments to an NSDictionary (rather  
than have each command use getopt_long etc.) and maybe a few other  
things.

A minor concern is how a command can signal tm_dialog to wait for a  
semaphore, as is presently required by the nib-loading command (when  
given e.g. the -w option)

A bigger concern is what to do with backwards compatibility. Maybe it  
would be possible to let $DIALOG point at a script that rewrites the  
arguments, and then introduce a new variable for the new tm_dialog  
command.



From throw-away-1 at macromates.com  Thu Sep 20 15:26:31 2007
From: throw-away-1 at macromates.com (Allan Odgaard)
Date: Thu, 20 Sep 2007 17:26:31 +0200
Subject: [TxMt Plugins] Dialog API improvements
In-Reply-To: <9287B3B3-C9EE-4C2C-92A9-421EABADC7F2@macromates.com>
References: <9287B3B3-C9EE-4C2C-92A9-421EABADC7F2@macromates.com>
Message-ID: <D9747A11-8E71-46C5-A204-033B9CE9B1A8@macromates.com>

On 20/09/2007, at 16:45, Allan Odgaard wrote:

> [...]
> The restructuring I am envisioning is to move to a command based  
> system so that the basic syntax is:
>     tm_dialog ?command? [?options?]
> [...]

I should mention that another candidate is to use an object oriented  
approach, so we would have:

     tm_dialog create (window|menu|?)

And later that object could be manipulated with other commands.

Though given how only few of the commands follow the ?create,  
manipulate, dispose?-cycle, it is probably not a good interface.



From bibiko at eva.mpg.de  Thu Sep 20 16:01:48 2007
From: bibiko at eva.mpg.de (=?ISO-8859-1?Q?Hans-J=F6rg_Bibiko?=)
Date: Thu, 20 Sep 2007 18:01:48 +0200
Subject: [TxMt Plugins] Dialog API improvements
In-Reply-To: <D9747A11-8E71-46C5-A204-033B9CE9B1A8@macromates.com>
References: <9287B3B3-C9EE-4C2C-92A9-421EABADC7F2@macromates.com>
	<D9747A11-8E71-46C5-A204-033B9CE9B1A8@macromates.com>
Message-ID: <3DE256CC-A359-4237-968B-9C48E4B308F4@eva.mpg.de>

Hi,

my FIRST thought is something like that:


tm_dialog LISTTOKENS

tm_dialog UPDATETOKEN <token>

tm_dialog CLOSETOKEN <token>

tm_dialog WAITFORTOKEN <token>


tm_dialog SHOW PopupMenu WITH '{menuItems={title=A;};}'

tm_dialog SHOW RequestString WITH '{prompt=A;string=Hello;}' AS  
'centered modal'

tm_dialog SHOW OpenPanel AS 'modal centered' ADD Accessory.nib WITH  
'{...}'
tm_dialog WITH '{...}' SHOW OpenPanel AS 'modal centered'

tm_dialog SHOW SavePanel ADD Accessory.nib WITH '{...}' AS modal

tm_dialog SHOW InteractivePopupMenu WITH 'suggestions=(...);' AS  
'modal quiet'

tm_dialog SHOW HTMLTooltip WITH '{...}'

tm_dialog SHOW MyNib ASYNC CREATENEWITEMS '{...}' AS 'centered'  
WITHDEFAULTS '{...}'
tm_dialog AS centered SHOW MyNib CREATENEWITEMS '{...}' ASYNC


So you write a kind of an English sentence with variable word order.

The entire arguments could be parsed into a NSDictionary and sent to  
the 'super class' to dispatch.

Regards,

Hans


From chris at cjack.com  Thu Sep 20 16:34:22 2007
From: chris at cjack.com (Chris Thomas)
Date: Thu, 20 Sep 2007 12:34:22 -0400
Subject: [TxMt Plugins] Dialog API improvements
In-Reply-To: <D9747A11-8E71-46C5-A204-033B9CE9B1A8@macromates.com>
References: <9287B3B3-C9EE-4C2C-92A9-421EABADC7F2@macromates.com>
	<D9747A11-8E71-46C5-A204-033B9CE9B1A8@macromates.com>
Message-ID: <FF764194-6CA6-4802-BBEC-938FDF9349F4@cjack.com>


On Sep 20, 2007, at 11:26 AM, Allan Odgaard wrote:

> On 20/09/2007, at 16:45, Allan Odgaard wrote:
>
>> [...]
>> The restructuring I am envisioning is to move to a command based  
>> system so that the basic syntax is:
>>    tm_dialog ?command? [?options?]
>> [...]
>
> I should mention that another candidate is to use an object oriented  
> approach, so we would have:
>
>    tm_dialog create (window|menu|?)
>
> And later that object could be manipulated with other commands.
>
> Though given how only few of the commands follow the ?create,  
> manipulate, dispose?-cycle, it is probably not a good interface.

Reverse the order and it can be done without forcing other commands to  
conform: "tm_dialog (window|menu) create". That's probably the most  
flexible solution.

But, it might be better to use the former approach with different  
verbs: "show" for synchronous and "create" for asynchronous.  
"tm_dialog show menu", for example, makes perfect sense and allows the  
"create" verb to be added later if there's ever a reason to manipulate  
a menu asynchronously.

The implementation in the Dialog plugin would use the second argument  
as a key for the command subclass, and then dispatch the command line  
to the subclass. This has the side effect of possibly slightly  
simplifying the implementation of "tm_dialog help <noun>".

Chris



From joachimm at etek.chalmers.se  Fri Sep 21 03:34:43 2007
From: joachimm at etek.chalmers.se (Joachim =?iso-8859-1?Q?M=E5rtensson?=)
Date: Fri, 21 Sep 2007 05:34:43 +0200 (CEST)
Subject: [TxMt Plugins] Dialog API improvements
In-Reply-To: <FF764194-6CA6-4802-BBEC-938FDF9349F4@cjack.com>
References: <9287B3B3-C9EE-4C2C-92A9-421EABADC7F2@macromates.com>
	<D9747A11-8E71-46C5-A204-033B9CE9B1A8@macromates.com>
	<FF764194-6CA6-4802-BBEC-938FDF9349F4@cjack.com>
Message-ID: <52972.193.11.234.162.1190345683.squirrel@webmail.chalmers.se>

I prefer having the following interface

tm_dialog <option> --flag1
--flag2=/usr/bin/no/spaces/between/path/equal/and/flag

possibly with the special case

tm_dialog help <option>

which could be written as the not so special

tm_dialog <option> --help

the above has the benefit of not require a more involved parser.  I think
we should wait with the show and create keywords until there are enough
commands to warrant wandering of the 'tm_dialog <option> <--flag> path. I
do not think that the normal usage pattern of tm_dialog requires anything
more involved, I would guess that people write a command once and stores
it in a {rb,py}. Calling it by hand from the Command Line is probably a
very uncommon behavior (except when debugging). What I am trying to say is
that while more involved schemas look cool they are more complicated to
write and in the end there will be very few cheering for our insane coding
skills anyway.

here is some data-structures I wrote for an overhaul of the system
yesterday. I made the decision to not support tm_dialog show-dialog
nibFile.nib but instead enforce tm_dialog show-dialog --file=nibFile.nib

struct subCommand {
    const char *commandName;
    void (*func)(std::map<std::string,std::string> strings,
    	std::map<std::string,bool> bools, int argc,  char * argv[]);
    const char* options[10];
    const char* mandatory[10];
};

static struct subCommand commands[] = {
/* name , call_funtion, optional flags, mandatory flags */
    {"create-alert", create_alert, {"parameters="}
    ,0},
    {"create-window",create_window,{"parameters=","center","defaults=","modal","quiet"},{"file="}},
    {"create-extended-popup",create_extended_popup,{"parameters="},0},
    {"create-menu",create_menu, {"parameters="},0},
    {"create-async-window",create_async_window,
        {"parameters=","center","defaults=","new-items="},{"file="}},
    {"close-window",close_window,
    {0},
    {"token="}},
    {"update-window",update_window,{0},{"token="}},
    {"wait-for-input",wait_for_input,{0},{"token="}},
    {"list-windows",list_window,{0},0}};
flags ending with = takes an argument.

I guess I could switch from stdlib types to cocoa ones, the struct
converted to some plist thing, perhaps the classes could conform to some
protocol so that they could supply which optional and mandatory flags they
support. and then a generic parser could be used if someone wanted that?

Joachim M?rtensson





From chris at cjack.com  Fri Sep 21 04:50:38 2007
From: chris at cjack.com (Chris Thomas)
Date: Fri, 21 Sep 2007 00:50:38 -0400
Subject: [TxMt Plugins] Dialog API improvements
In-Reply-To: <52972.193.11.234.162.1190345683.squirrel@webmail.chalmers.se>
References: <9287B3B3-C9EE-4C2C-92A9-421EABADC7F2@macromates.com>
	<D9747A11-8E71-46C5-A204-033B9CE9B1A8@macromates.com>
	<FF764194-6CA6-4802-BBEC-938FDF9349F4@cjack.com>
	<52972.193.11.234.162.1190345683.squirrel@webmail.chalmers.se>
Message-ID: <F2F6ABEC-5658-41DE-A4E3-125DB187E88C@cjack.com>


On Sep 20, 2007, at 11:34 PM, Joachim M?rtensson wrote:

> the above has the benefit of not require a more involved parser.  I  
> think
> we should wait with the show and create keywords until there are  
> enough
> commands to warrant wandering of the 'tm_dialog <option> <--flag>  
> path. I
> do not think that the normal usage pattern of tm_dialog requires  
> anything
> more involved, I would guess that people write a command once and  
> stores
> it in a {rb,py}. Calling it by hand from the Command Line is  
> probably a
> very uncommon behavior (except when debugging). What I am trying to  
> say is
> that while more involved schemas look cool they are more complicated  
> to
> write and in the end there will be very few cheering for our insane  
> coding
> skills anyway.

I prefer to stick with "--switch" for optional arguments, but I think  
you actually simplify the implementation slightly if you use an  
"object-oriented" syntax. The core dispatching code for a noun-verb  
("create|show|close window") would look something like:

@implementation TMUIServer
- (void)dispatchCommandLine:(NSArray *)commandLineItems
{
	// We must have a verb and a noun (TODO: handle --version)
	NSParameterAssert([commandLineItems count] > 2);
	
	NSString *		verb = [commandLineItems objectAtIndex:0];
	NSString *		noun = [commandLineItems objectAtIndex:1];
	
	// Find the command corresponding to the noun (TODO: this could be  
lazier and instantiate objects on demand)
	TMUICommand *	UICommand = [sSubcommandDictionary objectForKey:noun];
	
	// Dispatch the verb to the noun
	NSString *		methodName = [NSString stringWithFormat:@"perform 
%@WithArguments:", [verb capitalizedString]];
	SEL 			methodSelector = NSSelectorFromString(methodName);
	
	if([UICommand respondsToSelector:methodSelector])
	{
		id error = objc_msgSend(UICommand, methodSelector, commandLineItems);
	}
	else
	{
		// raise exception...
	}
}
@end

Parsing the remainder of the arguments would be the subcommand's  
responsibility, probably using a method provided for that purpose in  
the base class. This structure provides the property that any changes  
to a subcommand, even to accept a different set of arguments, are  
limited to that subcommand's source code. It allows new commands to be  
added without modifying any common code.

You can do the same thing with a single subcommand name ("tm_dialog  
create-window file.nib") as a part of the command name by storing a  
"command -> [class, selector]" mapping instead of the simpler "noun ->  
class" mapping. But I think I still prefer the "noun verb" syntax,  
because it enforces two desirable attributes when creating new  
commands: (a) the command is readable in source code and (b) there is  
room for future expansion.

Chris



From joachimm at etek.chalmers.se  Fri Sep 21 05:18:00 2007
From: joachimm at etek.chalmers.se (Joachim =?iso-8859-1?Q?M=E5rtensson?=)
Date: Fri, 21 Sep 2007 07:18:00 +0200 (CEST)
Subject: [TxMt Plugins] Dialog API improvements
In-Reply-To: <F2F6ABEC-5658-41DE-A4E3-125DB187E88C@cjack.com>
References: <9287B3B3-C9EE-4C2C-92A9-421EABADC7F2@macromates.com>
	<D9747A11-8E71-46C5-A204-033B9CE9B1A8@macromates.com>
	<FF764194-6CA6-4802-BBEC-938FDF9349F4@cjack.com>
	<52972.193.11.234.162.1190345683.squirrel@webmail.chalmers.se>
	<F2F6ABEC-5658-41DE-A4E3-125DB187E88C@cjack.com>
Message-ID: <53384.193.11.234.162.1190351880.squirrel@webmail.chalmers.se>


> I prefer to stick with "--switch" for optional arguments, but I think
> you actually simplify the implementation slightly if you use an
> "object-oriented" syntax. The core dispatching code for a noun-verb
> ("create|show|close window") would look something like:
>
Ok I was under the impression that some nouns would go without verb,
making it non obvious when to use which, I am fine with the above.

> Parsing the remainder of the arguments would be the subcommand's
> responsibility, probably using a method provided for that purpose in
> the base class. This structure provides the property that any changes
> to a subcommand, even to accept a different set of arguments, are
> limited to that subcommand's source code. It allows new commands to be
> added without modifying any common code.
I agree with this as well.

>
> You can do the same thing with a single subcommand name ("tm_dialog
> create-window file.nib") as a part of the command name by storing a
> "command -> [class, selector]" mapping instead of the simpler "noun ->
> class" mapping. But I think I still prefer the "noun verb" syntax,
I find it a bit verbose and unfamilar (I do not think I have used many
shell commands that use
this structure), but I have no proplems accepting it if it is what people
want.
> because it enforces two desirable attributes when creating new
> commands: (a) the command is readable in source code and (b) there is
> room for future expansion.
>
> Chris
>
> _______________________________________________
> textmate-plugins mailing list
> textmate-plugins at lists.macromates.com
> http://lists.macromates.com/mailman/listinfo/textmate-plugins
>




From bibiko at eva.mpg.de  Fri Sep 21 07:21:36 2007
From: bibiko at eva.mpg.de (=?ISO-8859-1?Q?Hans-J=F6rg_Bibiko?=)
Date: Fri, 21 Sep 2007 09:21:36 +0200
Subject: [TxMt Plugins] Dialog API improvements
In-Reply-To: <53384.193.11.234.162.1190351880.squirrel@webmail.chalmers.se>
References: <9287B3B3-C9EE-4C2C-92A9-421EABADC7F2@macromates.com>
	<D9747A11-8E71-46C5-A204-033B9CE9B1A8@macromates.com>
	<FF764194-6CA6-4802-BBEC-938FDF9349F4@cjack.com>
	<52972.193.11.234.162.1190345683.squirrel@webmail.chalmers.se>
	<F2F6ABEC-5658-41DE-A4E3-125DB187E88C@cjack.com>
	<53384.193.11.234.162.1190351880.squirrel@webmail.chalmers.se>
Message-ID: <AA90B2A4-64B7-4D48-93A6-EE4FEAFAEF14@eva.mpg.de>

HI,

OK, let me ask: Who are writing a tm_dialog command? I guess the  
majority of user is more or less skilled in writing source code. So,  
the 'old-fashioned' way by using argument options should not be a  
problem.

The only thing to do is to name these options more consistently.

OLD:
  -e, --alert
  -u, --menu
  -a, --async-window

  -c, --center
  -d, --defaults
  -n, --new-items
  -m, --modal
  -p, --parameters
  -q, --quiet

  -l, --list-windows
  -t, --update-window
  -x, --close-window
  -w, --wait-for-input

NEW:
  -s, --show <InlineMenu,OpenPanel {<accessory view  
nib>},RequestString,Alert,MyNIB,HTMLToolTip,InteractivePopUp...> => sync
  -i, --init <nib_file> => async

  -c, --center
  -d, --defaults <plist>
  -n, --new-items <plist>
  -m, --modal
  -p, --parameters <plist>
  -q, --quiet

  -l, --list-windows <token>
  -r, --refresh-window <token>
  -k, --kill-window <token>
  -w, --wait-for-input <token>


Note for options -s: if the first argument is a system panel like  
Open, Save, ColorPicker, etc. check whether it follows a nib file for  
the accessory view.

This would have the advantages that you can use both argument  
structures, meaning the backwards compatibility would be solved, and  
it would be easy to expand the existing source code.



Hans


From rix.rob at gmail.com  Fri Sep 21 07:30:27 2007
From: rix.rob at gmail.com (Rob Rix)
Date: Fri, 21 Sep 2007 03:30:27 -0400
Subject: [TxMt Plugins] Dialog API improvements
In-Reply-To: <53384.193.11.234.162.1190351880.squirrel@webmail.chalmers.se>
References: <9287B3B3-C9EE-4C2C-92A9-421EABADC7F2@macromates.com>
	<D9747A11-8E71-46C5-A204-033B9CE9B1A8@macromates.com>
	<FF764194-6CA6-4802-BBEC-938FDF9349F4@cjack.com>
	<52972.193.11.234.162.1190345683.squirrel@webmail.chalmers.se>
	<F2F6ABEC-5658-41DE-A4E3-125DB187E88C@cjack.com>
	<53384.193.11.234.162.1190351880.squirrel@webmail.chalmers.se>
Message-ID: <174DB72F-94D1-4E91-A076-2BB088C56635@gmail.com>

>> You can do the same thing with a single subcommand name ("tm_dialog
>> create-window file.nib") as a part of the command name by storing a
>> "command -> [class, selector]" mapping instead of the simpler "noun  
>> ->
>> class" mapping. But I think I still prefer the "noun verb" syntax,
> I find it a bit verbose and unfamilar (I do not think I have used many
> shell commands that use
> this structure), but I have no proplems accepting it if it is what  
> people
> want.

e.g. git and svn have fairly verbose syntaxes; the various Rails  
scripts tend to also, although that's a less compelling case.

I'm in favour.

Rob


From bibiko at eva.mpg.de  Fri Sep 21 08:59:00 2007
From: bibiko at eva.mpg.de (=?ISO-8859-1?Q?Hans-J=F6rg_Bibiko?=)
Date: Fri, 21 Sep 2007 10:59:00 +0200
Subject: [TxMt Plugins] Dialog API improvements
In-Reply-To: <AA90B2A4-64B7-4D48-93A6-EE4FEAFAEF14@eva.mpg.de>
References: <9287B3B3-C9EE-4C2C-92A9-421EABADC7F2@macromates.com>
	<D9747A11-8E71-46C5-A204-033B9CE9B1A8@macromates.com>
	<FF764194-6CA6-4802-BBEC-938FDF9349F4@cjack.com>
	<52972.193.11.234.162.1190345683.squirrel@webmail.chalmers.se>
	<F2F6ABEC-5658-41DE-A4E3-125DB187E88C@cjack.com>
	<53384.193.11.234.162.1190351880.squirrel@webmail.chalmers.se>
	<AA90B2A4-64B7-4D48-93A6-EE4FEAFAEF14@eva.mpg.de>
Message-ID: <7838785E-6D9A-4F7A-90C1-802BE24A3E98@eva.mpg.de>


On 21.09.2007, at 09:21, Hans-J?rg Bibiko wrote:
> NEW:
>  -s, --show <InlineMenu,OpenPanel {<accessory view  
> nib>},RequestString,Alert,MyNIB,HTMLToolTip,InteractivePopUp...> =>  
> sync
>  -i, --init <nib_file> => async
>
>  -c, --center
>  -d, --defaults <plist>
>  -n, --new-items <plist>
>  -m, --modal
>  -p, --parameters <plist>
>  -q, --quiet
>
>  -l, --list-windows <token>
>  -r, --refresh-window <token>
>  -k, --kill-window <token>
>  -w, --wait-for-input <token>
>

Furthermore one could set not only $DIALOG but also the following  
variables in order to abbreviate common used commands:

$DILAOG_SHOWNIB nib plist => tm_dialog -m -s $1 -p $2
$DIALOG_INITNIB nib plist => tm_dialog -i $1 -p $2
$DIALOG_SHOWPANEL panel {nib} plist => tm_dialog -s $1 (argc==3)? 
$2:"" -p (argc==3)?$3:$2
...

and I forgot the option -h for help. This option would open a pdf/ 
html/man... file showing a complete manual with examples for tm_dialog.

Chris' suggestion with:
- (void)dispatchCommandLine:(NSArray *)commandLineItems{}

is a very flexible approach and has many advantages.

The question is: What will the future bring us? As far as I  
understood the philosophy of tm_dialog it is a tool to provide the  
user 'only' with several kinds of dialog windows. There are some  
things which are in my mind and worth to be added to tm_dialog, e.g.  
to place the window to given origin point or place it under the  
caret's position, to change some attributes of the window or of nib  
components in respect of appearance, fading, resizing etc. but all  
these things can be specified within the PLIST. This would also mean  
that options like '-c' and '-q' could be set within the PLIST if one  
understand the PLIST as parameters which control the content AND the  
appearance of the given nib.

Other commands like Play a self-defined macro, or Execute a batch of  
bundle macros, snippets, commands, templates, etc. belongs to an  
other plug-in.

By my opinion: Keep things simple as possible.

--Hans

PS:
On totally other approach I read in the internet is to specify the  
behaviour of the nib within the nib as hidden Switches, Radio  
Buttons, etc.. That would mean you have Radio Buttons for Sync and  
Async; Switches for quiet, modal, and centered etc. These have a  
default and can be overwritten. But I believe this is not adoptable  
to tm_dialog.




From throw-away-1 at macromates.com  Fri Sep 21 16:57:02 2007
From: throw-away-1 at macromates.com (Allan Odgaard)
Date: Fri, 21 Sep 2007 18:57:02 +0200
Subject: [TxMt Plugins] Dialog API improvements
In-Reply-To: <FF764194-6CA6-4802-BBEC-938FDF9349F4@cjack.com>
References: <9287B3B3-C9EE-4C2C-92A9-421EABADC7F2@macromates.com>
	<D9747A11-8E71-46C5-A204-033B9CE9B1A8@macromates.com>
	<FF764194-6CA6-4802-BBEC-938FDF9349F4@cjack.com>
Message-ID: <62584438-8DD6-4EC6-B609-3F454A0894F4@macromates.com>

On 20/09/2007, at 18:34, Chris Thomas wrote:

> [...]
> Reverse the order and it can be done without forcing other commands  
> to conform: "tm_dialog (window|menu) create". That's probably the  
> most flexible solution.
>
> But, it might be better to use the former approach with different  
> verbs: "show" for synchronous and "create" for asynchronous.  
> "tm_dialog show menu", for example, makes perfect sense and allows  
> the "create" verb to be added later if there's ever a reason to  
> manipulate a menu asynchronously.
>
> The implementation in the Dialog plugin would use the second  
> argument as a key for the command subclass, and then dispatch the  
> command line to the subclass. This has the side effect of possibly  
> slightly simplifying the implementation of "tm_dialog help <noun>".

I like this a lot, I?ll write some code to support this probably later  
tonight.



From bibiko at eva.mpg.de  Mon Sep 24 13:10:39 2007
From: bibiko at eva.mpg.de (Hans-Joerg Bibiko)
Date: Mon, 24 Sep 2007 15:10:39 +0200
Subject: [TxMt Plugins] Dialog Plugin: HTMLTip problem
Message-ID: <F5B1450F-A428-4074-BF14-22B5703EABE3@eva.mpg.de>


Hi,

some days ago I downloaded the Ciar?n Walsh's code for the new HTMLTip.
I compiled it and I had the problem that:

[webView stringByEvaluatingJavaScriptFromString:@"return  
document.body.offsetHeight + document.body.offsetTop;"];

returns always (null) regardless of the JavaScript, meaning I 'saw'  
the tooltip with the content size 0,0.
If I set height and width by hand the dialog runs fine.

Then I tried it out on my good old G4 iMac and it works perfectly !?

The only difference between both Macs is Safari. On my G4 I run  
Safari 2.0.4, and on my new Mac I run Safari 3.0.3. After reading a  
bit I guess that the problem only occurs if one has installed Safari  
3.x. With the new Safari version it also comes a new WebKit version.

Up to now I didn't find a solution for that.

Any ideas?


Cheers,

Hans

From bibiko at eva.mpg.de  Mon Sep 24 14:40:05 2007
From: bibiko at eva.mpg.de (Hans-Joerg Bibiko)
Date: Mon, 24 Sep 2007 16:40:05 +0200
Subject: [TxMt Plugins] Dialog Plugin: HTMLTip problem
In-Reply-To: <F5B1450F-A428-4074-BF14-22B5703EABE3@eva.mpg.de>
References: <F5B1450F-A428-4074-BF14-22B5703EABE3@eva.mpg.de>
Message-ID: <EDCC354A-83CB-4728-8F5A-B0E14B21B36A@eva.mpg.de>


On 24 Sep 2007, at 15:10, Hans-Joerg Bibiko wrote:

>
> Hi,
>
> some days ago I downloaded the Ciar?n Walsh's code for the new  
> HTMLTip.
> I compiled it and I had the problem that:
>
> [webView stringByEvaluatingJavaScriptFromString:@"return  
> document.body.offsetHeight + document.body.offsetTop;"];
>

I fixed this for Safari 3.0.3!

Instead of using 'stringByEvaluatingJavaScriptFromString' I use now  
'[[webView windowScriptObject] evaluateWebScript]' and it works.

- (void)sizeToContent
{
	NSPoint pos = NSMakePoint([[self window] frame].origin.x, [[self  
window] frame].origin.y + [[self window] frame].size.height);
//	int height  = [[webView  
stringByEvaluatingJavaScriptFromString:@"return  
document.body.offsetHeight + document.body.offsetTop;"] intValue];
//	int width   = [[webView  
stringByEvaluatingJavaScriptFromString:@"return  
document.body.offsetWidth + document.body.offsetLeft;"] intValue];
	id wsc = [webView windowScriptObject];
	int height  = [[wsc evaluateWebScript:@"document.body.offsetHeight +  
document.body.offsetTop;"] intValue];
	int width   = [[wsc evaluateWebScript:@"document.body.offsetWidth +  
document.body.offsetLeft;"] intValue];
	[[self window] setContentSize:NSMakeSize(width, height)];
....


--Hans

From philip_orr at hotmail.com  Sun Sep 30 10:35:43 2007
From: philip_orr at hotmail.com (Philip Orr)
Date: Sun, 30 Sep 2007 03:35:43 -0700 (PDT)
Subject: [TxMt Plugins] Plugin Info
Message-ID: <12964445.post@talk.nabble.com>


I'm looking to try and develop a plug-in for Textmate and was looking to find
some good downloadable examples or tutorials. Do you know of any or can
point me in the right direction.

Thanks
-- 
View this message in context: http://www.nabble.com/Plugin-Info-tf4542913.html#a12964445
Sent from the textmate-plugins mailing list archive at Nabble.com.



From philip_orr at hotmail.com  Sun Sep 30 11:15:02 2007
From: philip_orr at hotmail.com (Philip Orr)
Date: Sun, 30 Sep 2007 04:15:02 -0700 (PDT)
Subject: [TxMt Plugins] Plugin Info
Message-ID: <12964445.post@talk.nabble.com>


I'm looking to try and develop a plug-in for Textmate and was looking to find
some good downloadable examples or tutorials. Do you know of any or can
point me in the right direction.

Thought I'd add a little of what I'm trying to do:
When the user selected a file from the panel view, it is passed to my
application where I can get the extension value and do something with the
file.

I've downloaded the clock example but it seems to simply add itself to the
window menu item and display a window with text.

Hope you can help out,
Thanks.
-- 
View this message in context: http://www.nabble.com/Plugin-Info-tf4542913.html#a12964445
Sent from the textmate-plugins mailing list archive at Nabble.com.



From ciawal at gmail.com  Sun Sep 30 18:26:35 2007
From: ciawal at gmail.com (=?UTF-8?Q?Ciar=C3=A1n_Walsh?=)
Date: Sun, 30 Sep 2007 19:26:35 +0100
Subject: [TxMt Plugins] Plugin Info
In-Reply-To: <12964445.post@talk.nabble.com>
References: <12964445.post@talk.nabble.com>
Message-ID: <AA125561-883D-4877-9404-82F4E6366E76@gmail.com>


On 30 Sep 2007, at 12:15, Philip Orr wrote:

> I'm looking to try and develop a plug-in for Textmate

There is no API for plugin development (and hence no manual/ 
tutorials). I think you?d want to hack into the project outline  
view?s delegate (OakProjectController, from memory) and insert your  
own delegate method for selection changes  
(outlineView:shouldSelectItem: from memory). Then you?d just do  
whatever you want with the info and return YES.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macromates.com/textmate-plugins/attachments/20070930/95482955/attachment.html>

From philip_orr at hotmail.com  Sun Sep 30 21:07:38 2007
From: philip_orr at hotmail.com (Philip Orr)
Date: Sun, 30 Sep 2007 14:07:38 -0700 (PDT)
Subject: [TxMt Plugins] Plugin Info
In-Reply-To: <AA125561-883D-4877-9404-82F4E6366E76@gmail.com>
References: <12964445.post@talk.nabble.com>
	<AA125561-883D-4877-9404-82F4E6366E76@gmail.com>
Message-ID: <12970169.post@talk.nabble.com>


You would think that something as popular as Textmate would have a complete
development sub section with tutorials. I'll have a look at the
OakProjectController and OakTextView. 

This is going to be a very uphill struggle me's thinks.



Ciar?n Walsh-3 wrote:
> 
> 
> On 30 Sep 2007, at 12:15, Philip Orr wrote:
> 
>> I'm looking to try and develop a plug-in for Textmate
> 
> There is no API for plugin development (and hence no manual/ 
> tutorials). I think you?d want to hack into the project outline  
> view?s delegate (OakProjectController, from memory) and insert your  
> own delegate method for selection changes  
> (outlineView:shouldSelectItem: from memory). Then you?d just do  
> whatever you want with the info and return YES.
> _______________________________________________
> textmate-plugins mailing list
> textmate-plugins at lists.macromates.com
> http://lists.macromates.com/mailman/listinfo/textmate-plugins
> 
> 

-- 
View this message in context: http://www.nabble.com/Plugin-Info-tf4542913.html#a12970169
Sent from the textmate-plugins mailing list archive at Nabble.com.